C++ Coding Standards

codingstandards-0-automatedanalysis.md

C++ Coding Standards Part 0: Automated Code Analysis

Automated analysis is the main advantage to working with a modern statically typed compiled language like C++.

Compilers

All reasonable warning levels should be enabled.

GCC / Clang

A good combination of settings is -Wall -Wextra -Wshadow -Wnon-virtual-dtor -pedantic

• -Wall -Wextra: reasonable and standard
• -Wshadow: warn the user if a variable declaration shadows another with the same name in the same scope
• -Wnon-virtual-dtor: warn the user if a class with virtual functions has a non-virtual destructor. This can lead to hard to track down memory errors
• -pedantic: warn about non-portable code, C++ that uses language extensions.

Static Analyzers

Code Coverage Analysis

codingstandards-1-requirements.md

C++ Coding Standards Part 1: Requirements

Style

Style guidelines are not overly strict. The important thing is that code is clear and readable with an appropriate amount of whitespace and reasonable length lines.

2 spaces indent level.

Tabs are not allowed, and a mixture of tabs and spaces is strictly forbidden. Modern autoindenting IDEs and editors require a consistent standard to be set.

// Good Idea
int myFunction(bool t_b)
{
  if (t_b)
  {
    // do something
  }
}

{} are required for blocks.

Leaving them off can lead to semantic errors in the code.

// Bad Idea
// this compiles and does what you want, but can lead to confusing
// errors if close attention is not paid.
for (int i = 0; i < 15; ++i)
  std::cout << i << std::endl;

// Bad Idea
// the cout is not part of the loop in this case even though it appears to be
int sum = 0;
for (int i = 0; i < 15; ++i)
  ++sum;
  std::cout << i << std::endl;
  
  
// Good Idea
// It's clear which statements are part of the loop (or if block, or whatever)
int sum = 0;
for (int i = 0; i < 15; ++i) {
  ++sum;
  std::cout << i << std::endl;
}

Keep lines a reasonable length

// Bad Idea
// hard to follow
if (x && y && myFunctionThatReturnsBool() && caseNumber3 && (15 > 12 || 2 < 3)) { 
}

// Good Idea
// Logical grouping, easier to read
if (x && y && myFunctionThatReturnsBool() 
    && caseNumber3 
    && (15 > 12 || 2 < 3)) { 
}

Unit Tests

<> vs ""

Safety

Use Exceptions Instead of Return Values

Avoid raw memory access

Raw memory access, allocation and deallocation are difficult to get correct in C++ without risking memory errors and leaks. C++11 provides tools to avoid these problems.

// Bad Idea
MyClass *myobj = new MyClass;

// ...
delete myobj;


// Good Idea
std::shared_ptr<MyClass> myobj = make_shared<MyClass>();
// ... 
// myobj is automatically freed for you whenever it is no longer used.

Avoid global data

... this includes singleton objects

Global data leads to unintended sideeffects between functions and can make code difficult or impossible to parallelize. Even if the code is not intended today for parallelization, there is no reason to make it impossible for the future.

codingstandards-2-guidelines.md

C++ Coding Standards Part 2: Guidelines

Style

Initialize Member Variables

with the member initializer list

// Bad Idea
class MyClass
{
public:
  MyClass(int t_value)
  {
    m_value = t_value;
  }

private:
  int m_value;
};


// Good Idea
// C++'s memeber initializer list is unique to the language and leads to
// cleaner code and potential performance gains that other languages cannot 
// match
class MyClass
{
public:
  MyClass(int t_value)
    : m_value(t_value)
  {
  }

private:
  int m_value;
};

Performance

Prefer pre-increment to post-increment

... when it is semantically correct. Pre-increment is faster then post-increment because it does not require a copy of the object to be made.

// Bad Idea
for (int i = 0; i < 15; i++)
{
  std::cout << i << std::endl;
}


// Good Idea
for (int i = 0; i < 15; ++i)
{
  std::cout << i << std::endl;
}

Const as much as possible

const tells the compiler that a variable or method is immutable. This helps the compiler optimize the code and helps the developer know if a function side effects. Also, using const & prevents the compiler from copying data unnecessarily.

// Bad Idea
class MyClass
{
public:
  MyClass(std::string t_value)
    : m_value(t_value)
  {
  }

  std::string get_value() 
  {
    return m_value;
  }

private:
  std::string m_value;
}


// Good Idea
class MyClass
{
public:
  MyClass(const std::string &t_value)
    : m_value(t_value)
  {
  }

  std::string get_value() const
  {
    return m_value;
  }

private:
  std::string m_value;
}

Very nice and detailed, thank you.

Thank you :)

Thanks!

Thank you,it was really helpful.

nice..helpful

This is great!

Veeeery helpful.

thank you:)

Great! thank you.

Nice!

Thanks!

Thank you!

Thanks

Should use string_view instead of const std::string &

The link to Google's standard is broken (my guess is because Google Code is gone). This is the new one: https://google.github.io/styleguide/cppguide.html

Also dead is the sourceforge one, but I have no idea where that is.

I just noticed that people are commenting on this gist. This file has not been maintained in many years. All of this has been moved to the much better organized online C++ Best Practices book.

https://github.com/lefticus/cppbestpractices/blob/master/00-Table_of_Contents.md

I just noticed that people are commenting on this gist. This file has not been maintained in many years. All of this has been moved to the much better organized online C++ Best Practices book.

https://github.com/lefticus/cppbestpractices/blob/master/00-Table_of_Contents.md

Okay thanks.