Coding Standards

[diagramatic]

Hi there,

What coding standards are most important to you? I'm doing a review and would like to get some feedback.

Naming conventions, is m_ used these days?
Class Names - prefixes, case?
Comments - style, on functions?
Do people prefer to use == NULL or == 0?

Any feedback would be great.

Thanks.

[Ryaether]

Well I can tell you that in C++ I prefer 0 to NULL

http://www2.research.att.com/~bs/bs_faq2.html#null

[Ancient Dragon]

I perfor { and } on separate lines, inline methods/functions when they consist of only one or two lines, and int main() instead of void main()

#include <iostream>
using std::cout;

int main()
{
   if( somethod )
   {
      cout << "Somethig here\n";
   }
   else
   {
      cout << "Something else here\n";
   }
}

[mrnutty]

Some styles that I use :

class Class{ //Classes start with capital letter
 m_var;
};

bool func(){ //notice the '{' being in the same line as the function 
}

int *p = 0;

string firstNameList; //naming convention

I use the "//" inline comment usually, for short and concise code. And use the "/**/" multiple line comment for larger functions when necessary.

[thelamb]

I find a lot of things important, here is a summary:

int myFunction( int arg1, int arg2 )
{
  if( 2 == arg1 ) // would throw error if I'd write 2 = argc1 by mistake
    return;       // And I generally thing it makes sense to write the constant                       on the left

   string myString = "Hello"; // Multiple variables are aligned
   int    test     = 5;
   int*   pTest    = NULL;    
}

int    myFunction     ( ); // Also aligned
string myOtherFunction( );

I tend to use NULL over 0, as it's the same anyway I find that using NULL shows the programmers intention better (don't start a war over this, it is my opinion that I'm not forcing on anyone ;)).

And yes, I mostly use m_ for my private variables, pure habit.

[Ancient Dragon]

>> // Multiple variables are aligned

The only place that might make a difference in in a structure to avoid holes.

[thelamb]

Huh? I think we have a miscommunication here ;)
By aligned I mean that the start of the variable names are at the same column.
I guess you meant aligned in memory?

// Not like:
int test;
string test2;

// But:
int    test
string test2;

[Ancient Dragon]

Oh -- yes I misunderstood. By alignment I thought you meant on 1, 2, 4, 16 ... byte boundries.

[chiwawa10]

Emphasis should also be given to naming convention used for variable, method and class names. They should be short, precise and descriptive. It is one of the area that is not given its due diligence.
Imagine yourself read a function name and wondering what the heck does this function do! I believe all of us here have encountered such situation.

[mrnutty]

Huh? I think we have a miscommunication here ;)
By aligned I mean that the start of the variable names are at the same column.
I guess you meant aligned in memory?

// Not like:
int test;
string test2;

// But:
int    test
string test2;

string name;
float value;
int id;

vs.

string    name;
float     value;
int       id;

And for me the second one is harder to maintain, because say you wanted to add a vector iterator like so :

string name;
float value;
int id;
vector<int>::iterator it;

vs:

string    name;
float     value;
int       id;
vector<int>::iterator it;

but notice that they aren't all aligned. So you would have to now re-tab the other variables like so :

string                name;
float                 value;
int                   id;
vector<int>::iterator it;

yea for me that doesn't sound like an advantage. Just an opinion though.

[mike_2000_17]

In my opinion, there are things that are important, others not so much. What I can think of, off the bat:

Important stuff includes:
- have clear names for classes and variables (identifiers), even if it makes them longer (IDE code-completion solves the extra typing issue, and it doesn't work if the variable or class name is not obvious and clear, and thus, "guessable").
- use all upper-case for the few MACROs that you might need, and include some prefix too, like MY_LIBRARY_SOME_MACRO instead of just SOME_MACRO.
- use namespaces a lot, because it frees the vocabulary and allows you to safely use good names for classes and variables without name clash dangers.
- provide full doxygen-style comments of each function, each class, each type, each member, each method, each every-freaken-thing that you find in a header file. And use the tags like \param, \return, \note, \test, \todo, \throw, \author, \date, etc.

Not so important, but still desirable IMO:
- be consistent with the capitals and other wording for everything that is public, i.e. class names, public and protected class methods and members, namespaces, global/namespaced functions, etc. I generally try to mimic the STL and the Boost conventions, which are essentially using all lower-case and _-separated words for class, namespace and type names, and leading lower-case, camel-back and no prefix (like m_ or p_) for data members and methods.
- put only trivial implementations in the header files, a few lines at most per function.

I also use NULL for pointer comparisons (and 0 for integers).