• Use zero (0) instead of NULL in C++ code.

  Rationale: "The C++ Programming Language", Third Edition, 5.1.1.

  "Due to C++'s tighter type checking, the use of plain 0, rather than any suggested NULL macro, leads to fewer problems."

• Put each declaration on a separate line:

  Example:

  int i;
  int j;
              

  Rationale: "The C++ Programming Language", Third Edition.

• Put the * and the & near the type, not the variable name:

  Example:

  int i;
  int* j
  int& k = i;
              

  Yes, it makes it difficult to write something like

  int *i, **j;
              

  but if you follow the previous advice and put every declaration on a separate line, you won't have to deal with it.

  Rationale: "The C++ Programming Language", Third Edition.

• Avoid the temptation of aligning the variable names in your declarations at a given column. Some type names will be longer, others will be shorter, you won't be able to be consistent, no matter how many tabs you use. For instance, how many tabs would you use if you have just one declaration in the middle of some code (like the "src" integer in this example)?

  Bad Example:

  int                     tmp;
  OptimizationType        ot;
  
  for (int i = 0; i < 10; i++)
      cout << i << endl;
  
  int                     src;
              

  The declaration of src looks weird. If you're tempted to remove the extra space before it, look a few lines up and see that this change will in turn make the formating inconsistent with the first two declarations. It is so much better to always separate the type from the name with just one space:

  Good Example:

  int tmp;
  OptimizationType ot;
  
  for (int i = 0; i < 10; i++)
      cout << i << endl;
  
  int src;
              

  Rationale: GNU Coding Standards.

• All class members (not member functions) should start with m_. This makes it easier to recognize them in any context, and makes naming constructor parameters much easier.

  Example:

  class X
  {
    private:
      int m_priority;
    public:
      X(int priority) : m_priority(priority) {}
  };
              

• All global variables (if you really need to use them) should start with a g_. Same rationale as for the members.
• Avoid the temptation of prefixing C++ variables with underscores. Find an intelligent names instead. Besides, if I remember correctly names beginning with two underscores are reserved in C++.
• Use short names for local variables, long names for class fields and functions. Methods should look like getPriority(), not get_priority().
• When you are creating new header files, please add the following text at the very end:

  // Local Variables:
  // mode: C++
  // End:
              

  Rationale: The .h extension is used for both C and C++, and when Emacs loads the file it will default to C mode. As a result, indentation will not work correctly in that file. If you add the above text at the end of the file, Emacs will understand that the file should be loaded in C++ mode and the indentation commands will work as expected.

• Protect your headers against multiple inclusions. Use the following convention:

  #ifndef _MODULE_Stem_H
  #define _MODULE_Stem_H
  
  ...
  
  #endif // _MODULE_Stem_H
              

  where "MODULE" should be replaced with the name of the module you are working on, and "Stem" with the name of the file (without the extension).
• Start each file with a small comment, a copyright notice, and the CVS Id (if using CVS):

  // Stem.h -- The interface provided by Stem objects.
  
  /*
   * Copyright (C) 2001 Free Software Foundation.
   * All rights reserved.
   */
  
  // $Id: Coding-Style-Cpp.phtml,v 1.2 2006/04/06 23:21:43 tudor Exp $
              

  The comment containing the CVS Id will be replaced/updated by CVS every time you commit. You don't need to manually adjust it. Don't worry if it goes beyond the 80 characters limit.
• Make sure that the first header file included in each .cc file is <config.h>:

  #ifdef HAVE_CONFIG_H
  #include <config.h>
  #endif
              

  This will include in your .cc files definitions of environment dependent flags that might affect the behavior of your code.

«Previous    1  2  3  4  5  6    Next»