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

Ollydbg: /* Commenting */ doxygen comment style

2014-02-10T14:15:15Z

Commenting: doxygen comment style

Thomas at 16:42, 11 November 2012

2012-11-11T16:42:19Z

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

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

2012-03-04T05:31:05Z

Header file include and Precompiled header rule =

Ollydbg: New section: include file and PCH rules

2012-03-04T05:30:48Z

New section: include file and PCH rules

Alpha at 22:39, 5 September 2011

2011-09-05T22:39:03Z

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

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

2006-09-01T09:41:46Z

Variables naming: break the long line a bit

Artojon: /* Commenting */ use list

2006-09-01T09:40:50Z

Commenting: use list

@@ Line 166: / Line 166: @@
 <source lang = "cpp">
 #include <wx_pch.h> // our PCH file, may include the WX PCH file (if needed)
@@ Line 183: / Line 182: @@
+}
 </source>
-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]

@@ 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.
 * Comments should clearly describe what the code does. Comments should be concise, but coherent.
 == Header file include and Precompiled header rule ==

@@ Line 49: / Line 49: @@
 bool someFunc(); // function with non-capital first letter
 </pre>
 == Variables declaration ==

← 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)]

@@ Line 100: / Line 100: @@
 * 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.

← 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]

@@ Line 1: / Line 1: @@
 [[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 ==

@@ 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.
-== Coding style ==
+== General coding style ==
 The general coding style is the ANSI one:
@@ Line 22: / Line 22: @@
+}
 </pre>
 == Variables naming ==

@@ Line 44: / Line 44: @@
 // 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,
 int m_someInt; // no capital letter 'S'
 void* m_SomePointer; // no m_p prefix
 bool someFunc(); // function with non-capital first letter
 </pre>
 == Variables declaration ==

@@ Line 95: / Line 95: @@
 == 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.