NRAO Home  >  Green Bank  |  Wiki Topic:    GB > Software > CppCodingStandards ( vs. r1.1)
   Changes | Index | Contents | Search | Statistics | Go
 <<O>>  Difference Topic CppCodingStandards (r1.1 - 26 Feb 2004 - AmyShelton)
Added:
>
>

%META:TOPICINFO{author="AmyShelton" date="1077819180" format="1.0" version="1.1"}%

C++ Programming Style


Program Layout:

  • Use spacing in source code just as you do in prose (or in mathematics).
  • Use a space after, but not before, punctuation such as a comma or semicolon. E.g. for (int i = 0; i < count; ++i)
  • Use four spaces for indention. Do not use tabs.
  • Curly brackets are indented in the same manner as their associated keyword and are on their own line.

Spelling, Abbreviation and Naming:

  • Avoid using reserved spellings (e.g. global variables with names beginning with an underscore).
  • Use an underscore between each word in identifiers formed from more than one word; use capitalization in those words as you do in prose. Class names are capitalized.
  • Don’t use an abbreviation for a long word when you can use a shorter synonym.
  • Don’t use an abbreviation unless it’s at least 3 (or so) characters shorter than the word it abbreviates.
  • If you must use an abbreviation, use a common one and use it consistently.
  • Don’t encode information about its implementation into the name of an abstract type (i.e. don’t name a pointer to a thing object thing_ptr).

Commenting:

  • If you can say something in the source code or say it in the comments, say it in the code. In other words, strive to make your code self-documenting.
  • Don’t use comments to repeat information that’s already in the code.
  • Comments should not be language or library tutorials.
  • Write comments that explain what each class does.
  • Carefully distinguish any comments that describe how a class works from those that describe what it does.
  • Write comments that explain what each non-member function does.

Other Gem’s Of Wisdom:

  • Declare each name in the smallest possible scope.
  • Declare each class member with the most restricted access possible.
  • Avoid public data members in classes that implement abstract types.
  • If necessary, use mutator functions to provided limited write access to non-public data members.
  • Avoid protect data members. Declare data members as private, and if necessary, provide protected accessor and mutator functions.
  • Define each inline member function in its header and after its class and use the keyword inline explicitly.
  • Prefer preincrement to postincrement where possible. E.g. for (int i = 0; i < count; ++i)

-- AmyShelton - 26 Feb 2004 %META:TOPICMOVED{by="AmyShelton" date="1077819222" from="Software.CPlusPlusCodingStandards" to="Software.CppCodingStandards"}%


Topic CppCodingStandards . { View | Diffs | r1.1 | More }
Revision -
Revision r1.1 - 26 Feb 2004 - 18:13 GMT - AmyShelton
Content copyright © 1999-2007 by the contributing authors.
All material on this collaboration platform is the property of the contributing authors.