Coding Standards - Revision history

Gajop at 00:25, 23 November 2018

2018-11-23T00:25:20Z

← Older revision		Revision as of 01:25, 23 November 2018
Line 29:		Line 29:

	For top-level types (struct/class/union/enum), braces go on the next line and for function definitions they may go on the same line:		For top-level types (struct/class/union/enum), braces go on the next line and for function definitions they may go on the same line:
	~~<code>~~<pre>		<pre>
	class CMyClass		class CMyClass
	{		{
Line 56:		Line 56:
	} while (condition1);		} while (condition1);
	}		}
	</pre~~></code~~>		</pre>

	For if-else statements (and similar), the following is also fine:		For if-else statements (and similar), the following is also fine:
	~~<code>~~<pre>		<pre>
	if (condition) {		if (condition) {
	}		}
	else {		else {
	}		}
	</pre~~></code~~>		</pre>

	For if's with a single line statement, it is preferred to omit the braces if no braces belonging to another control block follow immediately after the statement:		For if's with a single line statement, it is preferred to omit the braces if no braces belonging to another control block follow immediately after the statement:
	~~<code>~~<pre>		<pre>
	function() { // recommended		function() { // recommended
	if (condition)		if (condition)
Line 82:		Line 82:
	statement;		statement;
	}		}
	</pre~~></code~~>		</pre>

	==Naming==		==Naming==

	In Spring engine code, concrete classes are prefixed with C, interfaces with I, structs with S. Both use CamelCase. Functions and methods use CamelCase too. Parameters, fields, variables use pascalCase.		In Spring engine code, concrete classes are prefixed with C, interfaces with I, structs with S. Both use CamelCase. Functions and methods use CamelCase too. Parameters, fields, variables use pascalCase.
	~~<code>~~<pre>		<pre>
	// interface		// interface
	class ISkirmishAI		class ISkirmishAI
Line 100:		Line 100:
	char* myStr;		char* myStr;
	};		};
	</pre~~></code~~>		</pre>

	There are two exception to this however:		There are two exception to this however:
Line 119:		Line 119:

	On pointer or reference types, try to keep the respective symbol adjacent to the type:		On pointer or reference types, try to keep the respective symbol adjacent to the type:
	~~<code>~~<pre>		<pre>
	// better		// better
	char* myStr;		char* myStr;
Line 135:		Line 135:
	int * MyVar = (int *)OtherVar;		int * MyVar = (int *)OtherVar;
	void MyMethod(const std::string & myParam);		void MyMethod(const std::string & myParam);
	</pre~~></code~~>		</pre>

	If there is no type, keep the symbol adjacent to the variable name:		If there is no type, keep the symbol adjacent to the variable name:
	~~<code>~~<pre>		<pre>
	// better		// better
	char myChar, myCharPointer, *myCharDoublePointer;		char myChar, myCharPointer, *myCharDoublePointer;
Line 145:		Line 145:
	// bad		// bad
	char myChar, * myCharPointer, * * myCharDoublePointer;		char myChar, * myCharPointer, * * myCharDoublePointer;
	</pre~~></code~~>		</pre>

	For items separated by commas, e.g. function parameters and enums, keep one space after each comma:		For items separated by commas, e.g. function parameters and enums, keep one space after each comma:
	~~<code>~~<pre>		<pre>
	// good		// good
	void MyFun(int a, int b, int c);		void MyFun(int a, int b, int c);
Line 155:		Line 155:
	void MyFun(int a,int b,int c);		void MyFun(int a,int b,int c);
	int MyArr[3] = {1,2,3};		int MyArr[3] = {1,2,3};
	</pre~~></code~~>		</pre>

	For operators, e.g. =, + and -, keep one space on each side. Avoid using extra spaces around parentheses:		For operators, e.g. =, + and -, keep one space on each side. Avoid using extra spaces around parentheses:
	~~<code>~~<pre>		<pre>
	// good		// good
	void i = (1 - b);		void i = (1 - b);
Line 165:		Line 165:
	void i=( 1-b );		void i=( 1-b );
	void j=((1/b)+5)*c;		void j=((1/b)+5)*c;
	</pre~~></code~~>		</pre>

	==External dependencies==		==External dependencies==

Flozi: recat

2013-03-20T19:49:45Z

recat

← Older revision		Revision as of 20:49, 20 March 2013
Line 180:		Line 180:
	* [http://www.tiobe.com/content/paperinfo/gemrcsharpcs.pdf Philips Medical Systems - Coding Standard: C#] (free online book)		* [http://www.tiobe.com/content/paperinfo/gemrcsharpcs.pdf Philips Medical Systems - Coding Standard: C#] (free online book)

	[[Category:~~Development]] [[Category:Source development~~]]		[[Category:Engine Dev]]

Zerver: /* General */ Readability

2012-09-04T20:07:43Z

General: Readability

← Older revision		Revision as of 21:07, 4 September 2012
Line 113:		Line 113:

	Keep classes dedicated to a single function, do not create big monolithic classes which no one understands.		Keep classes dedicated to a single function, do not create big monolithic classes which no one understands.

			Insert a blank line to separate two parts of a function that have very distinct functionality. Otherwise try to keep the code compact with as few lines as possible, but avoid putting multiple statements on a single line and do not write lines more than 120 characters long.

	We use comment tags (TODO, FIXME, ..) as described [http://en.wikipedia.org/wiki/Comment_%28computer_programming%29#Tags here].		We use comment tags (TODO, FIXME, ..) as described [http://en.wikipedia.org/wiki/Comment_%28computer_programming%29#Tags here].

Zerver: /* Curly braces */ expand a bit

2012-09-04T19:57:56Z

Curly braces: expand a bit

← Older revision		Revision as of 20:57, 4 September 2012
Line 66:		Line 66:
	</pre></code>		</pre></code>

	For if's with a single line statement, it is preferred to omit the braces~~, especially~~ if no braces belonging to another control block follow immediately after the statement:		For if's with a single line statement, it is preferred to omit the braces if no braces belonging to another control block follow immediately after the statement:
	<code><pre>		<code><pre>
	if (condition) ~~// better~~		function() { // recommended
			if (condition)
	statement;		statement;
			if (condition) {
	if (condition) { ~~// okay~~
	statement;		statement;
	}		}
			}
			function() { // okay
			if (condition) {
			statement;
			}
			if (condition)
			statement;
			}
	</pre></code>		</pre></code>

Abma: /* Indentation */

2012-03-02T19:15:35Z

Indentation

← Older revision		Revision as of 20:15, 2 March 2012
Line 19:		Line 19:

	This implies that you should not use tabs in any other place then indentation. E.g. in the following sample use SPACE to align the constants.		This implies that you should not use tabs in any other place then indentation. E.g. in the following sample use SPACE to align the constants.
	<code~~><pre>~~		{{code\|
	#define LOS_INLOS 1		#define LOS_INLOS 1
	#define LOS_INRADAR 2		#define LOS_INRADAR 2
	~~</pre></code>~~		}}

	Do not attempt to align method parameters in a function call when breaking it over multiple lines. Just indent them using two tabs. Trying to align parameters with the opening parenthesis is unmaintainable: next time someone refactors the code and changes the function name, he has to go through all places it is used this way and waste his time inserting/removing spaces. Of course this applies to similar cases too; in general aligning stuff in such a way that an identifier rename requires realignment of all code using that identifier is bad practice.		Do not attempt to align method parameters in a function call when breaking it over multiple lines. Just indent them using two tabs. Trying to align parameters with the opening parenthesis is unmaintainable: next time someone refactors the code and changes the function name, he has to go through all places it is used this way and waste his time inserting/removing spaces. Of course this applies to similar cases too; in general aligning stuff in such a way that an identifier rename requires realignment of all code using that identifier is bad practice.

Jk at 05:53, 6 September 2011

2011-09-06T05:53:53Z

← Older revision		Revision as of 06:53, 6 September 2011
Line 1:		Line 1:
	<span class=warning>		<span class=warning>
	This document is not yet finished. Please add new points whenever they occur to you.		This document is not yet finished.<br>
			Please add new points whenever they occur to you.
	</span>		</span>

Jk: only style changes

2011-09-06T05:53:22Z

only style changes

← Older revision		Revision as of 06:53, 6 September 2011
Line 1:		Line 1:
	=~~= Spring engine coding standards ==~~		<span class=warning>
	~~=== Status ===~~

	This document is not yet finished. Please add new points whenever they occur to you.		This document is not yet finished. Please add new points whenever they occur to you.
			</span>

	=== Compiler ===		=Compiler=

	Keep in mind that we use gcc (g++) as the main compiler, likewise for linux and windows builds. So be sure your code compiles and works with gcc.		Keep in mind that we use gcc (g++) as the main compiler, likewise for linux and windows builds. So be sure your code compiles and works with gcc.

	=== Directory structure ===		=Directory structure=

	http://github.com/spring/spring/blob/master/directories.txt		http://github.com/spring/spring/blob/master/directories.txt

	=== Style ===		=Style=

	==== Indentation ====		==Indentation==

	Use tabs, not spaces. This allows anyone to choose their favorite indentation size.		Use tabs, not spaces. This allows anyone to choose their favorite indentation size.
Line 26:		Line 25:
	Do not attempt to align method parameters in a function call when breaking it over multiple lines. Just indent them using two tabs. Trying to align parameters with the opening parenthesis is unmaintainable: next time someone refactors the code and changes the function name, he has to go through all places it is used this way and waste his time inserting/removing spaces. Of course this applies to similar cases too; in general aligning stuff in such a way that an identifier rename requires realignment of all code using that identifier is bad practice.		Do not attempt to align method parameters in a function call when breaking it over multiple lines. Just indent them using two tabs. Trying to align parameters with the opening parenthesis is unmaintainable: next time someone refactors the code and changes the function name, he has to go through all places it is used this way and waste his time inserting/removing spaces. Of course this applies to similar cases too; in general aligning stuff in such a way that an identifier rename requires realignment of all code using that identifier is bad practice.

	==== Curly braces ====		==Curly braces==

	For top-level types (struct/class/union/enum), braces go on the next line and for function definitions they may go on the same line:		For top-level types (struct/class/union/enum), braces go on the next line and for function definitions they may go on the same line:
Line 76:		Line 75:
	</pre></code>		</pre></code>

	==== Naming ====		==Naming==

	In Spring engine code, concrete classes are prefixed with C, interfaces with I, structs with S. Both use CamelCase. Functions and methods use CamelCase too. Parameters, fields, variables use pascalCase.		In Spring engine code, concrete classes are prefixed with C, interfaces with I, structs with S. Both use CamelCase. Functions and methods use CamelCase too. Parameters, fields, variables use pascalCase.
Line 100:		Line 99:
	File-names are usually identical to the name of the main class that is inside, with the prefix stripped off. For example, <code>MySkirmishAI.cpp</code> for class <code>CMySkirmishAI</code>.		File-names are usually identical to the name of the main class that is inside, with the prefix stripped off. For example, <code>MySkirmishAI.cpp</code> for class <code>CMySkirmishAI</code>.

	==== General ====		==General==

	Try to keep code as readable as possible. This means, do not write very long functions, but split the problem in multiple functions. Use identifier names with an actual meaning as opposed to a,b,c, etc. The point is to allow other devs to "read" the code, as opposed to "figure it out".		Try to keep code as readable as possible. This means, do not write very long functions, but split the problem in multiple functions. Use identifier names with an actual meaning as opposed to a,b,c, etc. The point is to allow other devs to "read" the code, as opposed to "figure it out".
Line 157:		Line 156:
	</pre></code>		</pre></code>

	=== External dependencies ===		==External dependencies==

	Do not introduce new external dependencies without good motivation. The past has proven there are quite some libraries which just suck, do not build on some platform, are too buggy, make code unreadable, etc. If you really need to add a new dependency, be sure it is cross platform, and favor dependencies that are already packages in the major distributions like [http://www.debian.org/distrib/packages Debian] or [http://packages.ubuntu.com/ Ubuntu].		Do not introduce new external dependencies without good motivation. The past has proven there are quite some libraries which just suck, do not build on some platform, are too buggy, make code unreadable, etc. If you really need to add a new dependency, be sure it is cross platform, and favor dependencies that are already packages in the major distributions like [http://www.debian.org/distrib/packages Debian] or [http://packages.ubuntu.com/ Ubuntu].
Line 163:		Line 162:
	When working on Linux, remember to (get someone to) compile the dependency on Windows, both for MinGW and MSVC.		When working on Linux, remember to (get someone to) compile the dependency on Windows, both for MinGW and MSVC.

	== Sources ==		=Sources=

	(This is good material to at least skim through; the first one is a must have for every serious programmer.)		(This is good material to at least skim through; the first one is a must have for every serious programmer.)

Zerver: /* General */

2011-09-05T22:27:00Z

General

← Older revision		Revision as of 23:27, 5 September 2011
Line 113:		Line 113:
	char* myStr;		char* myStr;
	float* MyMethod(const char& myParam);		float* MyMethod(const char& myParam);
	~~float~~* ~~MyMethod~~(int* ~~myParam~~);		int* MyVar = (int*)OtherVar;
	void MyMethod(const std::string& myParam);		void MyMethod(const std::string& myParam);
	// okay		// okay
	char *myStr;		char *myStr;
	float *MyMethod(const char &myParam);		float *MyMethod(const char &myParam);
	~~float~~ ~~MyMethod~~(int ~~myParam~~);		int MyVar = (int )OtherVar;
	void MyMethod(const std::string &myParam);		void MyMethod(const std::string &myParam);
	// bad		// bad
	char * myStr;		char * myStr;
	float * MyMethod(const char & myParam);		float * MyMethod(const char & myParam);
	~~float~~ * ~~MyMethod~~(int * ~~myParam~~);		int * MyVar = (int *)OtherVar;
	void MyMethod(const std::string & myParam);		void MyMethod(const std::string & myParam);
	</pre></code>		</pre></code>

Zerver: /* General */ Operators

2011-09-05T22:22:17Z

General: Operators

@@ Line 145: / Line 145: @@
    void MyFun(int a,int b,int c);
    int MyArr[3] = {1,2,3};
 </pre></code>

Zerver: /* General */ Commas

2011-09-05T22:16:46Z

General: Commas

@@ Line 135: / Line 135: @@
    // bad
    char myChar, * myCharPointer, * * myCharDoublePointer;
 </pre></code>