Coding style - Revision history

Mgimenez: /* Header file include and Precompiled header rule */ Fix external links

2022-01-14T12:24:56Z

Header file include and Precompiled header rule: Fix external links

← Older revision		Revision as of 12:24, 14 January 2022
Line 166:		Line 166:

	<source lang = "cpp">		<source lang = "cpp">

	#include <wx_pch.h> // our PCH file, may include the WX PCH file (if needed)		#include <wx_pch.h> // our PCH file, may include the WX PCH file (if needed)

Line 183:		Line 182:
	}		}
	</source>		</source>
	~~See some disscussion in our forum: [/index.php/topic,16028.msg108172.html#msg108172 Morten's comments on include file rules]~~

	Also: [/index.php/topic,3321.msg26184.html#msg26184 include rules (by killerbot)]		See some disscussion in our forum: [https://forums.codeblocks.org/index.php/topic,16028.msg108172.html#msg108172 Morten's comments on include file rules]

			Also: [https://forums.codeblocks.org/index.php/topic,3321.msg26184.html#msg26184 include rules (by killerbot)]

Ollydbg: /* Commenting */ doxygen comment style

2014-02-10T14:15:15Z

Commenting: doxygen comment style

← Older revision		Revision as of 14:15, 10 February 2014
Line 105:		Line 105:
	* The Doxygen style is used for documenting functions only. These functions would be public, and protected class functions, and global helper functions.		* The Doxygen style is used for documenting functions only. These functions would be public, and protected class functions, and global helper functions.
	* Comments should clearly describe what the code does. Comments should be concise, but coherent.		* Comments should clearly describe what the code does. Comments should be concise, but coherent.

			=== Doxygen style comments ===
			This is the recommended Doxygen style, see [/index.php/topic,15948.msg107431.html#msg107431 comment style question] for details.
			<source lang = "cpp">
			/** Short description
			*
			* Long description
			*/
			</source>

	== Header file include and Precompiled header rule ==		== Header file include and Precompiled header rule ==

Thomas at 16:42, 11 November 2012

2012-11-11T16:42:19Z

← Older revision		Revision as of 16:42, 11 November 2012
Line 49:		Line 49:
	bool someFunc(); // function with non-capital first letter		bool someFunc(); // function with non-capital first letter
	</pre>		</pre>

			Parameters that are not absolutely required to be used in an interface or base class should preferrably be tagged with the <tt>cb_optional</tt> macro so users of the interface realize this, and as a side effect no compiler warnings are generated.

			Parameters that are ''actually not used'' should be tagged <tt>cb_unused</tt> both to suppress a compiler warning and indicate that this is happening intentionally.

			If the caller of a function takes ownership of the object referenced by the return value, tag the function as <tt>cb_must_consume_result</tt>.

	== Variables declaration ==		== Variables declaration ==

Ollydbg: /* Header file include and Precompiled header rule */ add one forum post by killerbot

2012-03-04T08:03:34Z

Header file include and Precompiled header rule: add one forum post by killerbot

← Older revision		Revision as of 08:03, 4 March 2012
Line 169:		Line 169:
	</source>		</source>
	See some disscussion in our forum: [/index.php/topic,16028.msg108172.html#msg108172 Morten's comments on include file rules]		See some disscussion in our forum: [/index.php/topic,16028.msg108172.html#msg108172 Morten's comments on include file rules]

			Also: [/index.php/topic,3321.msg26184.html#msg26184 include rules (by killerbot)]

Ollydbg: /* Header file include and Precompiled header rule = */

2012-03-04T05:31:05Z

Header file include and Precompiled header rule =

← Older revision		Revision as of 05:31, 4 March 2012
Line 100:		Line 100:
	* Comments should clearly describe what the code does. Comments should be concise, but coherent.		* Comments should clearly describe what the code does. Comments should be concise, but coherent.

	== Header file include and Precompiled header rule ===		== Header file include and Precompiled header rule ==
	The NON-PCH compilation (I mean with NOPCH switch, that's different from simply disabling PCH!) will be helpful to detect missing includes. Keep in mind that no matter what we do - wx will do and use PCH unless we declare NOPCH at the compile time. So even if we disable our PCH, the patches won't stop unless we do it properly in the first place.		The NON-PCH compilation (I mean with NOPCH switch, that's different from simply disabling PCH!) will be helpful to detect missing includes. Keep in mind that no matter what we do - wx will do and use PCH unless we declare NOPCH at the compile time. So even if we disable our PCH, the patches won't stop unless we do it properly in the first place.

Ollydbg: New section: include file and PCH rules

2012-03-04T05:30:48Z

New section: include file and PCH rules

← Older revision		Revision as of 05:30, 4 March 2012
Line 99:		Line 99:
	* The Doxygen style is used for documenting functions only. These functions would be public, and protected class functions, and global helper functions.		* The Doxygen style is used for documenting functions only. These functions would be public, and protected class functions, and global helper functions.
	* Comments should clearly describe what the code does. Comments should be concise, but coherent.		* Comments should clearly describe what the code does. Comments should be concise, but coherent.

			== Header file include and Precompiled header rule ===
			The NON-PCH compilation (I mean with NOPCH switch, that's different from simply disabling PCH!) will be helpful to detect missing includes. Keep in mind that no matter what we do - wx will do and use PCH unless we declare NOPCH at the compile time. So even if we disable our PCH, the patches won't stop unless we do it properly in the first place.

			The rules are plain simple:
			PCH file:
			- include all rarely changing header files
			- do the PCH macro vodoo (we have that already)
			Header:
			- If you access or define an object, include the header
			- If you use pointers/references, use forward decl
			- Put headers you need to include into such a section if they are part of your PCH file:
			Code:

			<source lang = "cpp">
			#ifndef USE_PCH
			#include <wx/dialog.h>
			#endif
			</source>

			- Include headers you need to include that are not part of your PCH file as normal
			Implementation:
			- include the PCH file first
			- same thing for headers needed as in the header file.

			I do it that way in my own projects and i works flawlessly for ages! Of course, whenever I change code and use new classes, I need to check the above rules.

			But (nevermind) if we decide to get rid of this because these rules are too hard - go ahead.

			Here comes a simple small class:
			Header:

			<source lang = "cpp">

			#ifndef USE_PCH
			#include <wx/dialog.h> // is in wx_pch.h!
			#endif

			#include <wx/busyinfo.h> // NOT in wx_pch.h and used as object

			class MyClass; // forward decsl due to pointer usage

			class MyDlg: public wxDialog
			{
			MyDlg() { ; };
			void Func(MyClass* c); // used as pointer
			wxBusyInfo bi; // used as object
			}
			</source>
			Implementation:

			<source lang = "cpp">

			#include <wx_pch.h> // our PCH file, may include the WX PCH file (if needed)

			#include "MyDlg.h"

			#ifndef USE_PCH
			#include "MyClass.h" // is in wx_pch.h, but now used as object / accessed
			#endif

			#include "MyOhterClass.h" // NOT in wx_pch.h and used as object

			void MyDlg::Func(MyClass* c)
			{
			MyOtherClass moc;
			c->DoSomething(moc);
			}
			</source>
			See some disscussion in our forum: [/index.php/topic,16028.msg108172.html#msg108172 Morten's comments on include file rules]

Alpha at 22:39, 5 September 2011

2011-09-05T22:39:03Z

← Older revision		Revision as of 22:39, 5 September 2011
Line 1:		Line 1:
	[[Category:Developer Documentation]]		[[Category:Developer Documentation]]
	The following are guidelines for the code formatting to use in Code::Blocks source code. Anyone writing code or a patch for Code::Blocks, is required to follow these.		The following are guidelines for the code formatting to use in Code::Blocks source code. Anyone writing code or a [[Creating a patch to submit to BerliOS (Patch Tracker)\|patch]] for Code::Blocks, is required to follow these.

	== General coding style ==		== General coding style ==

Artojon: /* Coding style */ the same sentence in the title and in the heading look weird to me

2006-09-01T09:43:13Z

Coding style: the same sentence in the title and in the heading look weird to me

← Older revision		Revision as of 09:43, 1 September 2006
Line 2:		Line 2:
	The following are guidelines for the code formatting to use in Code::Blocks source code. Anyone writing code or a patch for Code::Blocks, is required to follow these.		The following are guidelines for the code formatting to use in Code::Blocks source code. Anyone writing code or a patch for Code::Blocks, is required to follow these.

	== ~~Coding~~ style ==		== General coding style ==

	The general coding style is the ANSI one:		The general coding style is the ANSI one:
Line 22:		Line 22:
	}		}
	</pre>		</pre>


	== Variables naming ==		== Variables naming ==

Artojon: /* Variables naming */ break the long line a bit

2006-09-01T09:41:46Z

Variables naming: break the long line a bit

← Older revision		Revision as of 09:41, 1 September 2006
Line 44:		Line 44:

	// Bad		// Bad
	int SomeInt; // either no m_ prefix if it's a class variable, or capital first letter if it's a local variable		int SomeInt; // either no m_ prefix if it's a class variable,
			// or capital first letter if it's a local variable
	int m_someInt; // no capital letter 'S'		int m_someInt; // no capital letter 'S'
	void* m_SomePointer; // no m_p prefix		void* m_SomePointer; // no m_p prefix
	bool someFunc(); // function with non-capital first letter		bool someFunc(); // function with non-capital first letter
	</pre>		</pre>


	== Variables declaration ==		== Variables declaration ==

Artojon: /* Commenting */ use list

2006-09-01T09:40:50Z

Commenting: use list

← Older revision		Revision as of 09:40, 1 September 2006
Line 95:		Line 95:
	== Commenting ==		== Commenting ==

	All three types of comments are used in Code::Blocks. C++ style ('//'), C style ('/* /'), and the Doxygen style ('/* */').		* All three types of comments are used in Code::Blocks. C++ style ('//'), C style ('/* /'), and the Doxygen style ('/* */').
			* The C++ style is used for just about everything. Use this style to describe what your code does.
	The C++ style is used for just about everything. Use this style to describe what your code does.		* The C style is used only for very long comments (paragraphs), or for a license or description at the top of a C++ file.
			* The Doxygen style is used for documenting functions only. These functions would be public, and protected class functions, and global helper functions.
	The C style is used only for very long comments (paragraphs), or for a license or description at the top of a C++ file.		* Comments should clearly describe what the code does. Comments should be concise, but coherent.

	The Doxygen style is used for documenting functions only. These functions would be public, and protected class functions, and global helper functions.

	Comments should clearly describe what the code does. Comments should be concise, but coherent.