Coding Style - Revision history

Freddy77: typo fix

2009-01-16T09:15:27Z

typo fix

82.51.120.223: /* Functions */ typo

2008-03-09T15:27:19Z

‎Functions: typo

Kry: Better

2006-02-01T04:23:33Z

Better

Kry: =Brackets=

2006-02-01T04:23:14Z

=Brackets=

GonoszTopi: duplicate

2005-08-07T14:23:17Z

duplicate

GonoszTopi: =IMPORTANT: What to avoid (The special 'I kill you' section!)=

2005-08-07T14:21:32Z

=IMPORTANT: What to avoid (The special 'I kill you' section!)=

GonoszTopi: Not anymore.

2005-08-07T14:03:07Z

Not anymore.

82.80.34.93 at 21:20, 3 May 2005

2005-05-03T21:20:51Z

213.60.53.247: Adding wxStat ban and other minor stuff.

2005-04-27T23:38:27Z

Adding wxStat ban and other minor stuff.

Jacobo221 at 10:19, 31 March 2005

2005-03-31T10:19:35Z

@@ Line 113: / Line 113: @@
 === Lists/etc ===
-Only use raw arrays when absolutely nessesary, in ALL other cases use:
+Only use raw arrays when absolutely necessary, in ALL other cases use:
 ) STL containers, or
 ) wxWidgets containers

@@ Line 79: / Line 79: @@
 * Function names should follow the AllWordsAreUppercase convention
-* Function arguments should follow the conventions for local varibles described below
+* Function arguments should follow the conventions for local variables described below
 ===== Variables =====

@@ Line 40: / Line 40: @@
 === Brackets ===
-OOpening brackets are placed on the same line as the construct with the exception of non-inlined functions, structs and classes. Perfer the usage of brackets, even when optional, as in the case of ''if''/''while''/etc blocks.
+Opening brackets are placed on the same line as the construct with the exception of non-inlined functions, structs and classes. Prefer the usage of brackets, even when optional, as in the case of ''if''/''while''/etc blocks.
 === Misc ===

@@ Line 40: / Line 40: @@
 === Brackets ===
-Brackets are placed on the same line as the construct with the exception of non-inlined functions, structs and classes. Perfer the usage of brackets, even when optional, as in the case of ''if''/''while''/etc blocks.
+OOpening brackets are placed on the same line as the construct with the exception of non-inlined functions, structs and classes. Perfer the usage of brackets, even when optional, as in the case of ''if''/''while''/etc blocks.
 === Misc ===

@@ Line 49: / Line 49: @@
 == Documenting comments ==
-Always remember to documment new functions and classes! Examples of documented classes can be found in can be found in ''CMD4Hash.h'', ''BarShader.*'', ''ServerListCtrl.*'' and others. More information on the usage and syntax of [http://www.stack.nl/~dimitri/doxygen doxygen] can be found in the [http://www.stack.nl/~dimitri/doxygen/manual.html doxygen documentation].
+Always remember to documment new functions and classes! Examples of documented classes can be found in ''CMD4Hash.h'', ''BarShader.*'', ''ServerListCtrl.*'' and others. More information on the usage and syntax of [http://www.stack.nl/~dimitri/doxygen doxygen] can be found in the [http://www.stack.nl/~dimitri/doxygen/manual.html doxygen documentation].
 Use the following format, which is [http://www.stack.nl/~dimitri/doxygen doxygen] compatible.

← Older revision		Revision as of 14:21, 7 August 2005
Line 166:		Line 166:

	:''I said 'NEVER' because I meant 'NEVER'. No excuses at all, or you'll be drawn and quartered, and your parts will be exposed at the four corners of the [[aMule]] world as deterrent.''		:''I said 'NEVER' because I meant 'NEVER'. No excuses at all, or you'll be drawn and quartered, and your parts will be exposed at the four corners of the [[aMule]] world as deterrent.''
		+
		+	* Do NEVER EVER use [http://en.wikipedia.org/wiki/C_trigraph ANSI C trigraphs]. If you don't know what they are, you're lucky.
		+
		+	:''The above applies. In addition some keelhauling might be introduced.''

	* Do NEVER use 'malloc' or 'free' unless absolutely neccesary. Use 'new' and 'delete'.		* Do NEVER use 'malloc' or 'free' unless absolutely neccesary. Use 'new' and 'delete'.

@@ Line 165: / Line 165: @@
 * Do NEVER use CList/CTypedPtrList. This classes were a implementation of a MFC-compatible CList, and they are hand-made lists. they're known to be buggy and had to be fixed several times in the past. Instead, use stl containers or wxWidgets containers, as said on Lists/etc section. As a matter of fact, if you see a CList or CTypedPtrList on the code, clean it.
-:''There are places in the code still using those classes, mainly the part about averages that Emilio wrote for the stats. The reason for this is mainly some special functions for recycle nodes as head/tail he added to the CList class. While this improved performance, it breaks the rules, and we should consider cleaning it. Other than that, there's no excuse to use CList classes.''
+:''I said 'NEVER' because I meant 'NEVER'. No excuses at all, or you'll be drawn and quartered, and your parts will be exposed at the four corners of the [[aMule]] world as deterrent.''
 * Do NEVER use 'malloc' or 'free' unless absolutely neccesary. Use 'new' and 'delete'.

@@ Line 97: / Line 97: @@
 * Use ALLUPPERCASE names
-* Whenever possible, prefer const variables to pre-compiler defines. We've already had problems with nameclashing caused by defines, so me might as well not increase the chances of it happening again. Actual constants also has the major advantage that we gain proper type-safety.
+* Whenever possible, prefer const variables to pre-compiler defines. We've already had problems with nameclashing caused by defines, so we might as well not increase the chances of it happening again. Actual constants also has the major advantage that we gain proper type-safety.
 ===== Filenames =====

@@ Line 148: / Line 148: @@
 * Do NEVER use wxFind{First,Next}File. Use the CDirIterator class found in CFile.*. Reasons for this are the same as for wxFile and wxFFile: they don't handle unicode filenames properly.
 :''No, there's not exception for this. Just never use it.''
@@ Line 161: / Line 165: @@
 * Do NEVER use CList/CTypedPtrList. This classes were a implementation of a MFC-compatible CList, and they are hand-made lists. they're known to be buggy and had to be fixed several times in the past. Instead, use stl containers or wxWidgets containers, as said on Lists/etc section. As a matter of fact, if you see a CList or CTypedPtrList on the code, clean it.
-:''There are places in the code still using those classes, mainly the part about averages that Emilio wrote for the stats. The reason for this is aminly some special functions for recycle nodes as head/tail he added to the CList class. While this improved performance, it breaks the rules, and we should consider cleaning it. Other than that, there's no excuse to use CList classes.''
+:''There are places in the code still using those classes, mainly the part about averages that Emilio wrote for the stats. The reason for this is mainly some special functions for recycle nodes as head/tail he added to the CList class. While this improved performance, it breaks the rules, and we should consider cleaning it. Other than that, there's no excuse to use CList classes.''
-Probably more things I should remember, so I'll make this list bigger later.
+* Do NEVER use 'malloc' or 'free' unless absolutely neccesary. Use 'new' and 'delete'.
-=== Malloc ===
+:''A example of a place where malloc can (and must) be used, is when dealing with C-libs, in all other cases it should be avoided!''
-Only use malloc when it is absolutely necessary, for instance when dealing with C-libs, in all other cases it should be avoided!
 == Usefull information ==

@@ Line 137: / Line 137: @@
 * Do NEVER NEVER use unicode2char and char2unicode functions at all. Same for unicode2UTF8 and UTF82unicode, and anything related to converting unicode wxStrings into char or wchar buffers. This is specially true with functions dealing with interface, where we should ALWAYS use wxStrings, and never use string conversion to construct that wxString.
-''The only places this is allowed is on printf() calls for debug. And if you REALLY need to use them in other scenario, like network communication or file handling use them VERY carefully. There are comments about the proper use at the beggining of StringFunctions.h. If you don't know if it's right or what to use, just ask, probably Kry is the best one to reply to that questions. Make someone review the code if you're not experienced and want to use that.''
+:''The only places this is allowed is on printf() calls for debug. And if you REALLY need to use them in other scenario, like network communication or file handling use them VERY carefully. There are comments about the proper use at the beggining of StringFunctions.h. If you don't know if it's right or what to use, just ask, probably Kry is the best one to reply to that questions. Make someone review the code if you're not experienced and want to use that.''
 * Do NEVER use wxString::c_str() or wxString::GetData() or similar functions. If you ever need to do such thing, it must be one of the special cases above where unicode2char can be used.
-''If you, for some reason, know that the string is ANSI (like the MD4 hashes stored on wxStrings), you can use c_str() there (NEVER GetData()!) to avoid the CPU usage of the conversion functions, but you MUST put a big warning about it above the function call.''
+:''If you, for some reason, know that the string is ANSI (like the MD4 hashes stored on wxStrings), you can use c_str() there (NEVER GetData()!) to avoid the CPU usage of the conversion functions, but you MUST put a big warning about it above the function call.''
 * Do NEVER use wxFile or wxFFile - use CFile instead. It has several bugfixes over wxFile, and it will work perfectly for handling UTF8 filenames on unicode aMule, such as anything non-ascii.
-''There should be no problem using wxFile and wxFFile for amule-related files, like server.met and others, that are never non-ansi, but the use of CFile is advisable to keep coherence over the system and easier replacement when a valid wxFile is released from wxWidgets devs.''
+:''There should be no problem using wxFile and wxFFile for amule-related files, like server.met and others, that are never non-ansi, but the use of CFile is advisable to keep coherence over the system and easier replacement when a valid wxFile is released from wxWidgets devs.''
 * Do NEVER use wxFind{First,Next}File. Use the CDirIterator class found in CFile.*. Reasons for this are the same as for wxFile and wxFFile: they don't handle unicode filenames properly.
-''No, there's not exception for this. Just never use it.''
+:''No, there's not exception for this. Just never use it.''
 * Avoid wxDateTime::Now().Format{Time, Date} as if it were Satan itself. Mainly, it asserts and breaks on several locale, mainly chinese and other asian languages. Use wxDateTime::Now().FormatISO{Time, Date}. People will have to live with english formated date and time strings.
-''No excuses for this either. It will have to go like this till wx devs fix it.''
+:''No excuses for this either. It will have to go like this till wx devs fix it.''
 * When you use a string to build a wxString, like "aMule", you MUST use wxT("aMule") if you want it not to be translated and _("aMule") if you want it to be translated. Failure to do so will result in aMule not being compilable in unicode mode, and the coder responsive will be killed and buried alive, not neccesarily in that order.
-''As a side note, debug messages should be ALWAYS in english, and messages meant to be for the user should be translated. This is so we can read debug info without translating it.''
+:''As a side note, debug messages should be ALWAYS in english, and messages meant to be for the user should be translated. This is so we can read debug info without translating it.''
 * Do NEVER use CList/CTypedPtrList. This classes were a implementation of a MFC-compatible CList, and they are hand-made lists. they're known to be buggy and had to be fixed several times in the past. Instead, use stl containers or wxWidgets containers, as said on Lists/etc section. As a matter of fact, if you see a CList or CTypedPtrList on the code, clean it.
-''There are places in the code still using those classes, mainly the part about averages that Emilio wrote for the stats. The reason for this is aminly some special functions for recycle nodes as head/tail he added to the CList class. While this improved performance, it breaks the rules, and we should consider cleaning it. Other than that, there's no excuse to use CList classes.''
+:''There are places in the code still using those classes, mainly the part about averages that Emilio wrote for the stats. The reason for this is aminly some special functions for recycle nodes as head/tail he added to the CList class. While this improved performance, it breaks the rules, and we should consider cleaning it. Other than that, there's no excuse to use CList classes.''
 Probably more things I should remember, so I'll make this list bigger later.