** Using short names for loop variables is ok, e.g. '''i''', '''j'''. Otherwise use descriptive names and don't use abbreviations all over the place, to make the code more readable.

** Using short names for loop variables is ok, e.g. '''i''', '''j'''. Otherwise use descriptive names and don't use abbreviations all over the place, to make the code more readable.

* '''Inline methods''': Keep them short (max 10-15 lines at most).

* '''Inline methods''': Keep them short (max 10-15 lines at most).

-

* '''Documentation''': Use javadoc-style documentation for at least all public methods. Example:

+

* '''Documentation''': Use doxygen-style (javadoc-style?) documentation for at least all public methods. Example:

/**

/**

* The foo() method. Does some fooish stuff, yo!

* The foo() method. Does some fooish stuff, yo!

Line 16:

Line 16:

** Note: Documentation should go in to the header file.

** Note: Documentation should go in to the header file.

* '''Class definitions''': Put public methods at the top of the definition. They're usually the most interesting part from a user's point of view. Private stuff at the bottom.

* '''Class definitions''': Put public methods at the top of the definition. They're usually the most interesting part from a user's point of view. Private stuff at the bottom.

-

class Foo {

+

class Foo

+

{

public:

public:

Foo();

Foo();

Line 30:

Line 31:

private:

private:

/* private instance vars etc go here.*/

/* private instance vars etc go here.*/

-

}

+

};

-

** '''Instance variables''' should usually be accessible through getter and setter methods and thus be private. In some cases having them public is fine (e.g. when they're accessed all over the place and modifiying them happens all over the place as well. Usually this is the case for "dumb classes" used as pure data structures). Also, don't use prefixes for public instance variables, since it's ugly to use. For private instance variables we could choose to use either '''_foo''', '''m_foo''', '''mFoo''' etc. I personally prefer '''_foo''' and have a getter method be just '''foo()''' and a setter '''setFoo()'''.

+

** '''Instance variables''' should usually be accessible through getter and setter methods and thus be private. In some cases having them public is fine (e.g. when they're accessed all over the place and modifiying them happens all over the place as well. Usually this is the case for "dumb classes" used as pure data structures. We should consider using a '''struct''' instead for these cases.). Also, don't use prefixes for public instance variables, since it's ugly to use. For private instance variables we could choose to use '''m_foo''' and have a getter method be just '''foo()''' and a setter '''setFoo()'''.

Instance variables should usually be accessible through getter and setter methods and thus be private. In some cases having them public is fine (e.g. when they're accessed all over the place and modifiying them happens all over the place as well. Usually this is the case for "dumb classes" used as pure data structures. We should consider using a struct instead for these cases.). Also, don't use prefixes for public instance variables, since it's ugly to use. For private instance variables we could choose to use m_foo and have a getter method be just foo() and a setter setFoo().

Static (class) variables should start with just an underscore, e.g. _instance, _users etc.

Namespaces: We probably should use them.

Codeblocks: Use braces always for clarity and to prevent bugs while editing code