Programming Reference:Cpp Coding Style - Revision history

Mellinger: /* Example Function */

2021-02-23T09:57:56Z

Example Function

← Older revision		Revision as of 09:57, 23 February 2021
Line 77:		Line 77:

	void		void
	MyClass::MyFunction( const SomeClass& inTheInput, int& outTheResult )		MyClass::MyFunction(const SomeClass& inTheInput, int& outTheResult)
	{		{
	outTheResult = mSomeDataMember;		outTheResult = mSomeDataMember;
	for( int i = 0; i < inTheInput.NumIterations(); ++i )		for (int i = 0; i < inTheInput.NumIterations(); ++i)
	{		{
	int k = 4;		int k = 4;
	while( --k > 0 )		while (--k > 0)
	{		{
	outTheResult -= k;		outTheResult -= k;

Mellinger: /* Example Function */

2011-04-27T15:05:56Z

Example Function

← Older revision		Revision as of 15:05, 27 April 2011
Line 84:		Line 84:
	int k = 4;		int k = 4;
	while( --k > 0 )		while( --k > 0 )
			{
	outTheResult -= k;		outTheResult -= k;
			}
	}		}
	}		}

Mellinger: /* Line Formatting */

2011-04-27T14:52:57Z

Line Formatting

← Older revision		Revision as of 14:52, 27 April 2011
Line 20:		Line 20:

	== Line Formatting ==		== Line Formatting ==
	* Use tabs or spaces for '''indentation''' ~~but please~~ stay consistent within one file.		* Use tabs or spaces for '''indentation'''. Please stay consistent within one file.
	* Always use spaces for '''alignment'''; tab alignment will break when viewed with a different tab size.		* Always use spaces for '''alignment'''; tab alignment will break when viewed with a different tab size.
	* When using spaces for indentation, indent in steps of 2 or 3 space characters.		* When using spaces for indentation, indent in steps of 2 or 3 space characters.

Mellinger: /* Line Formatting */

2011-04-27T14:52:33Z

Line Formatting

← Older revision		Revision as of 14:52, 27 April 2011
Line 20:		Line 20:

	== Line Formatting ==		== Line Formatting ==
	* '''~~No tab characters~~''' (please ~~configure your editor to insert~~ spaces ~~instead)~~.		* Use tabs or spaces for '''indentation''' but please stay consistent within one file.
	* ~~Indentation~~ in steps of 2 or 3 space characters.		* Always use spaces for '''alignment'''; tab alignment will break when viewed with a different tab size.
			* When using spaces for indentation, indent in steps of 2 or 3 space characters.
	* Opening braces have their own line, aligned with the previous line; corresponding closing braces are placed on their own lines, at the same character position as the opening brace.		* Opening braces have their own line, aligned with the previous line; corresponding closing braces are placed on their own lines, at the same character position as the opening brace.
			* Consider giving single statements in if, while, or for clauses their own pair of braces.
	* For function definitions, return types appear on their own line, such that the function name is first in its line.		* For function definitions, return types appear on their own line, such that the function name is first in its line.

Mellinger: /* File Header */

2011-04-27T12:36:55Z

File Header

← Older revision		Revision as of 12:36, 27 April 2011
Line 4:		Line 4:
	Source files should provide a file header containing the following information:		Source files should provide a file header containing the following information:
	* an SVN file Id tag,		* an SVN file Id tag,
	* the file's original author(s), preferably identified by their email ~~address~~,		* the file's original author(s), preferably identified by their email addresses,
	* a description of the file's contents, i.e. typically a short information about the class declared/defined in the file,		* a description of the file's contents, i.e. typically a short information about the class declared/defined in the file,
	* a copyright note.		* a copyright note.

Mellinger: /* File Header */

2011-04-26T13:43:25Z

File Header

← Older revision		Revision as of 13:43, 26 April 2011
Line 13:		Line 13:
	// Description: A file header example. The header contains		// Description: A file header example. The header contains
	// an SVN Id tag, the author's email address, a short		// an SVN Id tag, the author's email address, a short
	// description of the file's content. and a copyright notice.		// description of the file's content, and a copyright notice.
	//		//
	// (C) 2000-~~2010~~, BCI2000 Project		// (C) 2000-2011, BCI2000 Project
	// http://www.bci2000.org		// http://www.bci2000.org
	///////////////////////////////////////////////////////////////////////		///////////////////////////////////////////////////////////////////////

Mellinger: /* Variable Declaration */

2011-04-26T13:22:25Z

Variable Declaration

← Older revision		Revision as of 13:22, 26 April 2011
Line 53:		Line 53:

	==Variable Declaration==		==Variable Declaration==
	* Always use the narrowest possible scope for a name to avoid side effects. E.g., this means to declare variables immediately before their first use, and to define loop counter variables within the loop's <for> statement.		* Always use the narrowest possible scope for a name to avoid side effects. E.g., this means to declare variables immediately before their first use, and to define loop counter variables within the loop's <tt>for</tt> statement.
	* Always initialize variables of elementary type at declaration resp. constructor to avoid reading from uninitialized memory. Examples of elementary types are <tt>int</tt>, <tt>float</tt>, and <tt>const char*</tt>.		* Always initialize variables of elementary type at declaration resp. constructor to avoid reading from uninitialized memory. Examples of elementary types are <tt>int</tt>, <tt>float</tt>, and <tt>const char*</tt>.

Mellinger: /* Name prefixes */

2011-04-26T13:21:58Z

Name prefixes

← Older revision		Revision as of 13:21, 26 April 2011
Line 37:		Line 37:
	=== Name prefixes ===		=== Name prefixes ===
	Prefixes should carry information about the ''scope and usage'' of a variable but ''not its type''.		Prefixes should carry information about the ''scope and usage'' of a variable but ''not its type''.
	*The rationale behind representing ''scope'' is to avoid accidental hiding of names from a wider scope by names with a narrower scope, which may lead to difficult-to-detect bugs.		*In terms of ''scope'', we discriminate between class members, static variables, global variables, and constants. The rationale behind representing ''scope'' is to avoid accidental hiding of names from a wider scope by names with a narrower scope, which may lead to difficult-to-detect bugs.
	*Representing ''usage'' makes it easier to maintain an overview over householding tasks, such as calling <tt>delete</tt> on pointers whose objects are owned by the code under review.		*Representing ''usage'' shows whether a variable is a pointer, or an input or output argument to a function. This makes it easier to maintain an overview over householding tasks, such as calling <tt>delete</tt> on pointers whose objects are owned by the code under review.
	*''Not'' representing ''type'' avoids name and type going out of sync--a variable's type is more likely to change than its scope and usage, and unreliable type information is less desirable than having no type information at all.		*''Not'' representing ''type'' avoids name and type going out of sync--a variable's type is more likely to change than its scope and usage, and unreliable type information is less desirable than having no type information at all.

Mellinger: /* Line Formatting */

2010-03-19T17:42:34Z

Line Formatting

← Older revision		Revision as of 17:42, 19 March 2010
Line 1:		Line 1:
	We maintain a loose set of guidelines/rules that is aimed at readability and maintenance efficiency. These rules are not obligatory, but we ask contributors to consider them before handing in their code.		We maintain a loose set of guidelines/rules that is aimed at readability and maintenance efficiency. These rules are not obligatory, but we ask contributors to consider them before handing in their code.

			==File Header==
			Source files should provide a file header containing the following information:
			* an SVN file Id tag,
			* the file's original author(s), preferably identified by their email address,
			* a description of the file's contents, i.e. typically a short information about the class declared/defined in the file,
			* a copyright note.
			An example header in a C++ source file might look like this:
			///////////////////////////////////////////////////////////////////////
			// $Id$
			// Author: gerd.gurke@gemuesenet.de
			// Description: A file header example. The header contains
			// an SVN Id tag, the author's email address, a short
			// description of the file's content. and a copyright notice.
			//
			// (C) 2000-2010, BCI2000 Project
			// http://www.bci2000.org
			///////////////////////////////////////////////////////////////////////

	== Line Formatting ==		== Line Formatting ==

Mellinger: /* Memory Allocation */

2010-03-18T17:12:39Z

Memory Allocation

← Older revision		Revision as of 17:12, 18 March 2010
Line 41:		Line 41:
	* Allocate objects from the '''stack''' rather than the '''heap''' unless there is a good reason to use the '''new''' operator. This avoids memory leaks.		* Allocate objects from the '''stack''' rather than the '''heap''' unless there is a good reason to use the '''new''' operator. This avoids memory leaks.
	* Use STL containers rather than allocating arrays with '''new[]'''. This eliminates a number of possible errors (initialization, allocation, deallocation).		* Use STL containers rather than allocating arrays with '''new[]'''. This eliminates a number of possible errors (initialization, allocation, deallocation).
			* Make sure to deallocate arrays using the '''delete[]''' operator (mind the brackets).

	==Pointers and References==		==Pointers and References==