[nemiver] Update Coding style
- From: Dodji Seketeli <dodji src gnome org>
- To: svn-commits-list gnome org
- Cc:
- Subject: [nemiver] Update Coding style
- Date: Sun, 20 Sep 2009 20:49:20 +0000 (UTC)
commit 10652a1c183ad0ed0a039a8f310135d7edef8ab1
Author: Dodji Seketeli <dodji redhat com>
Date: Sun Sep 20 22:05:10 2009 +0200
Update Coding style
* coding-style.txt: Shorten lines to < 80 characters and cleanup.
coding-style.txt | 87 ++++++++++++++++++++++++++++++++++--------------------
1 files changed, 55 insertions(+), 32 deletions(-)
---
diff --git a/coding-style.txt b/coding-style.txt
index 8b4110e..a23d175 100644
--- a/coding-style.txt
+++ b/coding-style.txt
@@ -1,18 +1,24 @@
-These coding styles are derived from the GNOME coding styles and have been adapted to better fit with C++.
-So, please read the http://developer.gnome.org/doc/guides/programming-guidelines/code-style.html as an introduction.
+These coding styles are derived from the GNOME coding styles and have been
+adapted to better fit with C++.
+So, please read
+http://developer.gnome.org/doc/guides/programming-guidelines/code-style.html
+as an introduction.
Be consistent
- As a rule of thumb, please try to use the style that was there before you, otherwise the code will be non consistent.
+ As a rule of thumb, please try to use the style that was there before you,
+ otherwise the code will be non consistent.
Lines and functions length
- 1. Don't write lines that are too long.
- Lots of people out there divide their screen in 2 vertical rectangles, each vertical rectangle
- being itself divided in two horizontal rectangles. So don't think everybody looks at only one file at a time, full screen.
- I won't say that each line should be 80 characters, so please, follow the "Be consitent" rule stated above.
- Do not make your lines longer than the code the lines already written in other parts of the code.
- 2. The same thing applies to functions length. Again, be consistent with the other parts of the code.
+ 1. Lines should be 80 characters long, at most.
+ Lots of people out there divide their screen in 2 vertical rectangles,
+ each vertical rectangle being itself divided in two horizontal rectangles.
+ So don't assume everybody looks at only one file at a time, full screen.
+ Or don't assume everybody has huge screens.
+ Generally speaking, be consitent. Do not make your lines longer than the
+ lines already written in other parts of the code.
+ 2. Similar things applies to functions length. Be consistent with the other parts of the code.
3. No function should contain more than 4 levels of indentation.
Indenting
@@ -24,12 +30,18 @@ Indenting
Naming conventions
- 1. function names are lowercase with underscores to separate words, like this : do_something_good () .
- 2. Macros and constants are uppercase, with underscore to separate words like: DO_SOMETHING () for a macro or NUMBER_OF_CHARS for a constant.
- 3. user defined types (classes, struct, enum names) are mixed upper and lowercase, like class ConfManager ;
- 4. don't pollute the global namespace. Every symbol should at least be in the 'nemiver' namespace (or in namespaces that are themselves in the nemiver namespace).
- 5. To help our fellow emacs users, don't use the keyword 'namespace' to define namespace, like "namespace foo { //blah}", otherwise, emacs indents
- //blah. Use the macro NEMIVER_BEGIN_NAMESPACE (foo) and NEMIVER_END_NAMESPACE (foo), instead. This helps emacs not to endent the content of the namespace.
+ 1. function names are lowercase with underscores to separate words,
+ like this : do_something_good () .
+ 2. Macros and constants are uppercase, with underscore to separate
+ words like: DO_SOMETHING () for a macro or NUMBER_OF_CHARS for a constant.
+ 3. user defined types (classes, struct, enum names) are mixed upper and lowercase,
+ like class ConfManager ;
+ 4. don't pollute the global namespace. Every symbol should at least be in the 'nemiver' namespace
+ (or in namespaces that are themselves in the nemiver namespace).
+ 5. To help our fellow emacs users, don't use the keyword 'namespace'
+ to define namespace, like "namespace foo { //blah}", otherwise, emacs indents
+ //blah. Use the macro NEMIVER_BEGIN_NAMESPACE (foo) and NEMIVER_END_NAMESPACE (foo), instead.
+ This helps emacs not to endent the content of the namespace.
6. Generaly, C++ data mambers should be prefixed by m_.
Functions
@@ -68,7 +80,9 @@ Functions
Braces
- 1. Function definitions â?? open and close braces should be on lines by themselves. Do not put the open brace on the same line as the function signature. For example:
+ 1. Function definitions â?? open and close braces should be on lines by
+ themselves. Do not put the open brace on the same line as the function
+ signature. For example:
Right:
@@ -91,7 +105,8 @@ Braces
// do stuff
}
- 2. Other braces, including for, while, do, switch statements and class definitions â?? the open brace should go on the same line as the as the control structure.
+ 2. Other braces, including for, while, do, switch statements and class
+ definitions â?? the open brace should go on the same line as the as the control structure.
Right:
for (int i = 0; i < 10; i++) {
@@ -105,12 +120,13 @@ Braces
// do stuff
}
- 3. If/else statements â?? as above, but if there is an else clause, the close brace should go on the same line as the else.
+ 3. If/else statements â?? as above, but if there is an else clause,
+ the close brace should go on the same line as the else.
Right:
if (time_to_go_buy_something) {
- go_buy(&something);
+ go_buy (&something);
} else if (time_to_go_home) {
// comment on else case
gone = true;
@@ -120,7 +136,7 @@ Braces
if (time_to_go_buy_something)
{
- go_buy(&something);
+ go_buy (&something);
// comment on else case
} else if (timeToGoHome)
gone = true;
@@ -135,8 +151,10 @@ Braces
Parentheses
- 1. Function declarations and calls â?? use one space between the name and the open parenthese, no space inside the parentheses, nor before commas
- that separate arguments. Do use a single space after commas that separate arguments.
+ 1. Function declarations and calls â?? use one space between the name and
+ the open parenthese, no space inside the parentheses, nor before commas
+ that separate arguments. Do use a single space after commas that
+ separate arguments.
Right:
@@ -151,14 +169,17 @@ Parentheses
int my_function ( int arg1 , float arg2 );
- 2. Control structures, such as if, while, do and switch â?? use a single space before the open paren, but no spaces inside the parentheses.
+ 2. Control structures, such as if, while, do and switch â?? use a single
+ space before the open paren, but no spaces inside the parentheses.
Null, false
1. The null pointer value should be written as 0.
- 2. True and false values of type bool, or just generic true/false values, should be written as true and false.
- 3. Tests for null pointers, false values and 0 values should all be done directly, not through an inequality or equality comparison.
+ 2. True and false values of type bool, or just generic true/false values,
+ should be written as true and false.
+ 3. Tests for null pointers, false values and 0 values should all be done directly,
+ not through an inequality or equality comparison.
Right:
@@ -216,16 +237,18 @@ Null, false
Generic stuff
- 1. variables that of builtin types must always be initialized at declaration time.
+ 1. variables of builtin types must always be initialized at
+ declaration time.
- Right:
+ Right:
- int foo=0 ;
+ int foo = 0 ;
- Wrong:
+ Wrong:
- int foo ;
+ int foo ;
- 2. always provide default constructors for user defined types (classes). If you don't want
- to be used with the default constructor, declare the default constructor private.
+ 2. always provide default constructors for user defined types (classes).
+ If you don't want to be used with the default constructor, declare
+ the default constructor private.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]