Most crucial elements in a light-weight C++ coding standard [closed]

Answer 1

Don't add types or functions to the global namespace.

Answer 2

Principle of least surprise.

Maybe it's not the "flavor" of rules you are looking for, but I'd definitely put it first.

It is not only the root, reason and sanity check for all the boring stuff like formatting and commenting guidelines, but - to me more importantly - puts the emphasis on the code being read and understood, rather than just compiled.

It also covers the only reasonable code quality measure I have ever encountered - WTF's per minute.

I'd use that first point to stress the importance and value of clear, consistent code, and to motivate the following items in the coding standard.

Answer 3

Public inheritance must model The Liskov Substitution Principle (LSP).

Code reuse/import without substituability must be implemented with private inheritance when a very strong coupling makes sense, or with aggregation otherwise.

Answer 4

Whatever guidelines, make it very easy to recognize applicability: the less choice you have, the less time you loose choosing. And the easier it becomes to brainparse the code.

Examples of 'hard to recognize':

• No braces if only one line in the conditional body
• Use K&R brace placement for namespaces, but put brace underneath conditions in function definition code
• ...

Answer 5

Use vector and string instead of C-style arrays and char *

Use std::vector whenever you need to create a buffer of data, even if the size is fixed.

Use std::string whenever you need to have a string.

How it clearly facilitates safer code, which minimizes the risk of enigmatic bugs, which increases maintainability, etc.?

std::vector: The user of a vector can always find its size, and the vector can be resized if needed. It can even be given (through the (&(myVector[0])) notation) to a C API. Of course, the vector will clean after itself.

std::string: Almost the same reasons above.And the fact it will always be correctly initialized, that it can't be overrun, that it will handle modifications gracefully, like concatenations, assignation, etc, and in a natural way (using operators instead of functions)

Answer 6

Never use structs without proper constructors

structs are legal C++ constructs, used to aggregate data together. Still, the data should be always properly initialized.

All C++ structs should have at least a default constructor, which will set its aggregated data to default values.

struct MyStruct // BAD
{
   int i ; bool j ; char * k ;
}

struct MyStruct // GOOD
{
   MyStruct() : i(0), j(true), k(NULL) : {}

   int i ; bool j ; char * k ;
}

And if they are usually initialized in some way, provide a constructor to enable the user to avoid a C-style struct initialization:

MyStruct oMyStruct = { 25, true, "Hello" } ; // BAD
MyStruct oMyStruct(25, true, "Hello") ;      // GOOD

How it clearly facilitates safer code, which minimizes the risk of enigmatic bugs, which increases maintainability, etc.?

Having struct without a proper constructor leaves the user of this struct the task of initializing it. So, the following code will be copy pasted from function to function:

void doSomething()
{
   MyStruct s = { 25, true, "Hello" } ;
  // Etc.
}

void doSomethingElse()
{
   MyStruct s = { 25, true, "Hello" } ;
  // Etc.
}

// Etc.

Which means that, in C++, if you need to add a field in the struct, or change the order of the internal data, you have to go through all these initializations to verify each is still correct. With a proper constructor, modifying the internals of the structs is decoupled from its use.