Skip to content

Instantly share code, notes, and snippets.

@lefticus
Last active August 26, 2024 10:03

Revisions

  1. lefticus revised this gist Oct 20, 2019. 4 changed files with 22 additions and 1 deletion.
    2 changes: 1 addition & 1 deletion codingstandards-0-automatedanalysis.md
    Original file line number Diff line number Diff line change
    @@ -2,7 +2,7 @@
    # IS OUT OF
    # DATE

    # See https://cppbestpractices.com Instead!
    # See https://github.com/lefticus/cppbestpractices/blob/master/00-Table_of_Contents.md Instead!

    # C++ Coding Standards Part 0: Automated Code Analysis

    7 changes: 7 additions & 0 deletions codingstandards-1-style.md
    Original file line number Diff line number Diff line change
    @@ -1,3 +1,10 @@
    # THIS DOCUMENT
    # IS OUT OF
    # DATE

    # See https://github.com/lefticus/cppbestpractices/blob/master/00-Table_of_Contents.md Instead!


    # C++ Coding Standards Part 1: 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. A few best practices are also mentioned.
    7 changes: 7 additions & 0 deletions codingstandards-2-performance_and_safety.md
    Original file line number Diff line number Diff line change
    @@ -1,3 +1,10 @@
    # THIS DOCUMENT
    # IS OUT OF
    # DATE

    # See https://github.com/lefticus/cppbestpractices/blob/master/00-Table_of_Contents.md Instead!


    # C++ Coding Standards Part 2: Performance and Safety

    ## Limit Variable Scope
    7 changes: 7 additions & 0 deletions codingstandards-3-references.md
    Original file line number Diff line number Diff line change
    @@ -1,3 +1,10 @@
    # THIS DOCUMENT
    # IS OUT OF
    # DATE

    # See https://github.com/lefticus/cppbestpractices/blob/master/00-Table_of_Contents.md Instead!


    # References and Further Reading


  2. lefticus revised this gist Oct 20, 2019. 1 changed file with 6 additions and 0 deletions.
    6 changes: 6 additions & 0 deletions codingstandards-0-automatedanalysis.md
    Original file line number Diff line number Diff line change
    @@ -1,3 +1,9 @@
    # THIS DOCUMENT
    # IS OUT OF
    # DATE

    # See https://cppbestpractices.com Instead!

    # 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++. Code analysis tools can inform us when we have implemented an operator overload with a non-canonical form, when we should have made a method const, or when the scope of a variable can be reduced.
  3. lefticus revised this gist Apr 27, 2014. 1 changed file with 5 additions and 0 deletions.
    5 changes: 5 additions & 0 deletions codingstandards-2-performance_and_safety.md
    Original file line number Diff line number Diff line change
    @@ -116,3 +116,8 @@ private:
    ```
    ## Prefer Stack Operations to Heap Operations
    Heap operations have performance penalties in mulithreaded environments on most platforms and can possibly lead to memory errors if not used carefully.
    Modern C++11 has special move operations which are designed to enhances the performance of stack based data by reducing or eliminating copies, which can bring even the single threaded case on par with heap based operations.
  4. lefticus revised this gist Apr 27, 2014. 1 changed file with 2 additions and 0 deletions.
    2 changes: 2 additions & 0 deletions codingstandards-2-performance_and_safety.md
    Original file line number Diff line number Diff line change
    @@ -26,6 +26,8 @@ for (int i = 0; i < 15; ++i)

    Exceptions cannot be ignored. Return values, such as using `boost::optional`, can be ignored and if not checked can cause crashes or memory errors. An exception, on the other hand, can be caught and handled. Potentially all the way up the highest level of the application with a log and automatic restart of the application.

    Stroustrup, the original designer of C++, [makes this point](http://www.stroustrup.com/bs_faq2.html#exceptions-why) much better than I ever could.

    ## Avoid raw memory access

    Raw memory access, allocation and deallocation, are difficult to get correct in C++ without [risking memory errors and leaks](http://blog2.emptycrate.com/content/nobody-understands-c-part-6-are-you-still-using-pointers). C++11 provides tools to avoid these problems.
  5. lefticus revised this gist Apr 27, 2014. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion codingstandards-3-references.md
    Original file line number Diff line number Diff line change
    @@ -2,7 +2,7 @@


    * http://geosoft.no/development/cppstyle.html
    * http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml (Not that google's standard document makes several recommendations which we will NOT be following. For example, they explicitly forbid the use of exceptions, which makes [RAII](http://blog2.emptycrate.com/content/nobody-understands-c-part-2-raii) impossible.)
    * http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml (Note that google's standard document makes several recommendations which we will NOT be following. For example, they explicitly forbid the use of exceptions, which makes [RAII](http://blog2.emptycrate.com/content/nobody-understands-c-part-2-raii) impossible.)
    * http://www.parashift.com/c++-faq/
    * http://www.cplusplus.com/
    * http://sourceforge.net/apps/mediawiki/cppcheck/index.php?title=ListOfChecks
  6. lefticus revised this gist Apr 27, 2014. 3 changed files with 40 additions and 13 deletions.
    17 changes: 15 additions & 2 deletions codingstandards-1-style.md
    Original file line number Diff line number Diff line change
    @@ -242,8 +242,21 @@ This is a proactive approach to simplify compilation time and rebuilding depende
    ## Always Use Namespaces
    There is almost never a reason to declare an identifier in the global namespaces. Instead, functions and classes should exist in an appropriately named namespaces or in a class inside of a namespace.
    There is almost never a reason to declare an identifier in the global namespaces. Instead, functions and classes should exist in an appropriately named namespaces or in a class inside of a namespace. Identifiers which are placed in the global namespace risk conflicting with identifiers from other (mostly C, which doesn't have namespaces) libraries.
    ## Avoid Compiler Macros
    Compiler definitions and macros
    Compiler definitions and macros are replaced by the pre-processor before the compiler is ever run. This can make debugging very difficult because the debugger doesn't know where the source came from.
    ```cpp
    // Good Idea
    namespace my_project {
    class Constants {
    public:
    static const double PI = 3.14159;
    }
    }
    // Bad Idea
    #define PI 3.14159;
    ```
    22 changes: 18 additions & 4 deletions codingstandards-2-performance_and_safety.md
    Original file line number Diff line number Diff line change
    @@ -1,12 +1,26 @@
    # C++ Coding Standards Part 2: Performance and Safety

    ## Limit Variable Scope

    ## Do Not Use C-Style Casts


    Variables should be declared as late as possible, and ideally, only when it's possible to initialize the object. Reduced variable scope results in less memory being used, more efficient code in general, and helps the compiler optimize the code further.

    ## Limit Variable Scope
    ```c++
    // Good idea
    for (int i = 0; i < 15; ++i)
    {
    MyObject obj(i);
    // do something with obj
    }

    // Bad Idea
    MyObject obj; // meaningless object initialization
    for (int i = 0; i < 15; ++i)
    {
    obj = MyObject(i); // unnecessary assignment operation
    // do something with obj
    }
    // obj is still taking up memory for no reason
    ```

    ## Use Exceptions Instead of Return Values to Indicate Error

    14 changes: 7 additions & 7 deletions codingstandards-3-references.md
    Original file line number Diff line number Diff line change
    @@ -1,9 +1,9 @@
    http://geosoft.no/development/cppstyle.html
    # References and Further Reading

    http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml

    http://www.parashift.com/c++-faq/

    http://www.cplusplus.com/

    http://sourceforge.net/apps/mediawiki/cppcheck/index.php?title=ListOfChecks
    * http://geosoft.no/development/cppstyle.html
    * http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml (Not that google's standard document makes several recommendations which we will NOT be following. For example, they explicitly forbid the use of exceptions, which makes [RAII](http://blog2.emptycrate.com/content/nobody-understands-c-part-2-raii) impossible.)
    * http://www.parashift.com/c++-faq/
    * http://www.cplusplus.com/
    * http://sourceforge.net/apps/mediawiki/cppcheck/index.php?title=ListOfChecks
    * http://emptycrate.com/
  7. lefticus revised this gist Apr 27, 2014. 3 changed files with 13 additions and 2 deletions.
    5 changes: 3 additions & 2 deletions codingstandards-1-style.md
    Original file line number Diff line number Diff line change
    @@ -1,6 +1,6 @@
    # C++ Coding Standards Part 1: 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.
    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. A few best practices are also mentioned.

    ## Descriptive and Consistent Naming

    @@ -244,5 +244,6 @@ This is a proactive approach to simplify compilation time and rebuilding depende
    There is almost never a reason to declare an identifier in the global namespaces. Instead, functions and classes should exist in an appropriately named namespaces or in a class inside of a namespace.
    ## Avoid Compiler Macros
    Compiler definitions and macros
    3 changes: 3 additions & 0 deletions codingstandards-2-performance_and_safety.md
    Original file line number Diff line number Diff line change
    @@ -1,6 +1,9 @@
    # C++ Coding Standards Part 2: Performance and Safety


    ## Do Not Use C-Style Casts



    ## Limit Variable Scope

    7 changes: 7 additions & 0 deletions codingstandards-3-references.md
    Original file line number Diff line number Diff line change
    @@ -1,2 +1,9 @@
    http://geosoft.no/development/cppstyle.html

    http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml

    http://www.parashift.com/c++-faq/

    http://www.cplusplus.com/

    http://sourceforge.net/apps/mediawiki/cppcheck/index.php?title=ListOfChecks
  8. lefticus revised this gist Apr 27, 2014. 1 changed file with 5 additions and 3 deletions.
    8 changes: 5 additions & 3 deletions codingstandards-0-automatedanalysis.md
    Original file line number Diff line number Diff line change
    @@ -1,10 +1,12 @@
    # 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++.
    Automated analysis is the main advantage to working with a modern statically typed compiled language like C++. Code analysis tools can inform us when we have implemented an operator overload with a non-canonical form, when we should have made a method const, or when the scope of a variable can be reduced.

    In short, these tools catch the most commonly agreed best practice mistakes we are making and help educate us to write better code. We will be fully utilizing these tools.

    ## Compilers

    All reasonable warning levels should be enabled.
    All reasonable warning levels should be enabled. Some warning levels, such as GCC's `-Weffc++` warning mode can be too noisy and will not be recommended for normal compilation.

    ### GCC / Clang

    @@ -37,7 +39,7 @@ Can be enabled with the `/analyze` [command line option](http://msdn.microsoft.c

    ## Code Coverage Analysis

    A coverage analysis tools shall be run when tests are executed to make sure the entire application is being tested. Unfortunately, coverage analysis requires that compiler optimizations be disabled. This can result in significantly longer test execution times.
    A coverage analysis tool shall be run when tests are executed to make sure the entire application is being tested. Unfortunately, coverage analysis requires that compiler optimizations be disabled. This can result in significantly longer test execution times.

    The most likely candidate for a coverage visualization is the [lcov](http://ltp.sourceforge.net/coverage/lcov.php) project. A secondary option is [coveralls](https://coveralls.io/), which is free for open source projects.

  9. lefticus revised this gist Apr 27, 2014. 4 changed files with 169 additions and 163 deletions.
    6 changes: 5 additions & 1 deletion codingstandards-0-automatedanalysis.md
    Original file line number Diff line number Diff line change
    @@ -44,4 +44,8 @@ The most likely candidate for a coverage visualization is the [lcov](http://ltp.

    ## Ignoring Warnings

    If it is determined by team consensus that the compiler or analyzer is warning on something that is either incorrect or unavoidable, the team will disable the specific error to as localized part of the code as possible.
    If it is determined by team consensus that the compiler or analyzer is warning on something that is either incorrect or unavoidable, the team will disable the specific error to as localized part of the code as possible.

    ## Unit Tests

    There should be a test enabled for every feature or bug fix that is committed. See also "Code Coverage Analysis."
    101 changes: 65 additions & 36 deletions codingstandards-1-requirements.md → codingstandards-1-style.md
    Original file line number Diff line number Diff line change
    @@ -1,10 +1,8 @@
    # C++ Coding Standards Part 1: Requirements

    ## Style
    # C++ Coding Standards Part 1: 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.

    ### Descriptive and Consistent Naming
    ## Descriptive and Consistent Naming

    C++ allows for arbitrary length identifier names, so there's no reason to be terse when naming variables. Use descriptive names, and be consistent in the style

    @@ -13,23 +11,23 @@ C++ allows for arbitrary length identifier names, so there's no reason to be ter

    are common examples. snake_case has the advantage that it can also work with spell checkers, if desired.

    #### Common C++ Naming Conventions
    ### Common C++ Naming Conventions

    * Types start with capitals: `MyClass`
    * functions and variables start with lower case: `myMethod`
    * constants are all capital: `const int PI=3.14159265358979323;`

    *Note that the C++ standard does not follow any of these guidelines. Everything in the standard is lowercase only.*

    #### Distinguish Private Object Data
    ### Distinguish Private Object Data

    Name private data with a `m_` prefix to distinguish it from public data.

    #### Distinguish Function Parameters
    ### Distinguish Function Parameters

    Name function parameters with an `t_` prefix.

    #### Well formed example
    ### Well formed example

    ```cpp
    class MyClass
    @@ -50,16 +48,16 @@ private:
    };
    ```
    ### Distinguish C++ Files From C Files
    ## Distinguish C++ Files From C Files
    C++ source file should be named `.cpp` or `.cc` NOT `.c`
    C++ header files should be named `.hpp` NOT `.h`
    ### Use `nullptr`
    ## Use `nullptr`
    C++11 introduces `nullptr` which is a special type denoting a null pointer value. This should be used instead of 0 or NULL to indicate a null pointer.
    ### Comments
    ## Comments
    Comment blocks should use `//`, not `/* */`. Using `//` makes it much easier to comment out a block of code while debugging.
    @@ -83,12 +81,12 @@ int myFunc()

    which would be impossible if the function comment header used `/* */`

    ### Never Use `using` In a Header File
    ## Never Use `using` In a Header File

    This causes the name space you are `using` to be pulled into the namespace of the header file.


    ### Include Guards
    ## Include Guards

    Header files must contain an distinctly named include guard to avoid problems with including the same header multiple times or conflicting with other headers from other projects

    @@ -104,7 +102,7 @@ class MyClass {
    #endif
    ```

    ### 2 spaces indent level.
    ## 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.

    @@ -119,7 +117,7 @@ int myFunction(bool t_b)
    }
    ```
    ### {} are required for blocks.
    ## {} are required for blocks.
    Leaving them off can lead to semantic errors in the code.
    ```cpp
    @@ -146,7 +144,7 @@ for (int i = 0; i < 15; ++i) {
    }
    ```

    ### Keep lines a reasonable length
    ## Keep lines a reasonable length

    ```cpp
    // Bad Idea
    @@ -162,11 +160,8 @@ if (x && y && myFunctionThatReturnsBool()
    }
    ```

    ### Unit Tests

    There should be a test enabled for every feature or bug fix that is committed. See also "Code Coverage Analysis."

    ### Use "" For Including Local Files
    ## Use "" For Including Local Files
    ... `<>` is [reserved for system includes](http://blog2.emptycrate.com/content/when-use-include-verses-include).

    ```cpp
    @@ -189,31 +184,65 @@ There should be a test enabled for every feature or bug fix that is committed. S
    #include "MyHeader.hpp"
    ```

    ## Safety
    ## Initialize Member Variables
    ...with the member initializer list

    ### Use Exceptions Instead of Return Values to Indicate Error
    ```cpp
    // Bad Idea
    class MyClass
    {
    public:
    MyClass(int t_value)
    {
    m_value = t_value;
    }

    Exceptions cannot be ignored. Return values, such as using `boost::optional`, can be ignored and if not checked can cause crashes or memory errors. An exception, on the other hand, can be caught and handled. Potentially all the way up the highest level of the application with a log and automatic restart of the application.
    private:
    int m_value;
    };

    ### Avoid raw memory access

    Raw memory access, allocation and deallocation, are difficult to get correct in C++ without [risking memory errors and leaks](http://blog2.emptycrate.com/content/nobody-understands-c-part-6-are-you-still-using-pointers). C++11 provides tools to avoid these problems.
    // 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;
    };
    ```
    ## Forward Declare when Possible
    This:
    ```cpp
    // Bad Idea
    MyClass *myobj = new MyClass;
    // some header file
    class MyClass;
    // ...
    delete myobj;
    void doSomething(const MyClass &);
    ```

    instead of:

    // Good Idea
    std::shared_ptr<MyClass> myobj = make_shared<MyClass>();
    // ...
    // myobj is automatically freed for you whenever it is no longer used.
    ```cpp
    // some header file
    #include "MyClass.hpp"

    void doSomething(const MyClass &);
    ```
    ### Avoid global data
    ... this includes singleton objects
    This is a proactive approach to simplify compilation time and rebuilding dependencies.
    ## Always Use Namespaces
    There is almost never a reason to declare an identifier in the global namespaces. Instead, functions and classes should exist in an appropriately named namespaces or in a class inside of a namespace.
    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.
    126 changes: 0 additions & 126 deletions codingstandards-2-guidelines.md
    Original file line number Diff line number Diff line change
    @@ -1,126 +0,0 @@
    # C++ Coding Standards Part 2: Guidelines

    ## Style

    ### Initialize Member Variables
    ...with the member initializer list

    ```cpp
    // 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;
    };
    ```
    ### Forward Declare when Possible
    This:
    ```cpp
    // some header file
    class MyClass;
    void doSomething(const MyClass &);
    ```

    instead of:

    ```cpp
    // some header file
    #include "MyClass.hpp"

    void doSomething(const MyClass &);
    ```
    This is a proactive approach to simplify compilation time and rebuilding dependencies.
    ## Performance
    ### Prefer pre-increment to post-increment
    ... when it is semantically correct. Pre-increment is [faster](http://blog2.emptycrate.com/content/why-i-faster-i-c) then post-increment because it does not require a copy of the object to be made.
    ```cpp
    // 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. [Here](http://kotaku.com/454293019) are some comments on const from John Carmack.

    ```cpp
    // 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;
    }
    ```
    99 changes: 99 additions & 0 deletions codingstandards-2-performance_and_safety.md
    Original file line number Diff line number Diff line change
    @@ -0,0 +1,99 @@
    # C++ Coding Standards Part 2: Performance and Safety



    ## Limit Variable Scope


    ## Use Exceptions Instead of Return Values to Indicate Error

    Exceptions cannot be ignored. Return values, such as using `boost::optional`, can be ignored and if not checked can cause crashes or memory errors. An exception, on the other hand, can be caught and handled. Potentially all the way up the highest level of the application with a log and automatic restart of the application.

    ## Avoid raw memory access

    Raw memory access, allocation and deallocation, are difficult to get correct in C++ without [risking memory errors and leaks](http://blog2.emptycrate.com/content/nobody-understands-c-part-6-are-you-still-using-pointers). C++11 provides tools to avoid these problems.

    ```cpp
    // 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.


    ## Prefer pre-increment to post-increment
    ... when it is semantically correct. Pre-increment is [faster](http://blog2.emptycrate.com/content/why-i-faster-i-c) then post-increment because it does not require a copy of the object to be made.

    ```cpp
    // 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. [Here](http://kotaku.com/454293019) are some comments on const from John Carmack.

    ```cpp
    // 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;
    }
    ```
  10. lefticus revised this gist Apr 27, 2014. 3 changed files with 56 additions and 0 deletions.
    33 changes: 33 additions & 0 deletions codingstandards-1-requirements.md
    Original file line number Diff line number Diff line change
    @@ -55,6 +55,39 @@ private:
    C++ source file should be named `.cpp` or `.cc` NOT `.c`
    C++ header files should be named `.hpp` NOT `.h`
    ### Use `nullptr`
    C++11 introduces `nullptr` which is a special type denoting a null pointer value. This should be used instead of 0 or NULL to indicate a null pointer.
    ### Comments
    Comment blocks should use `//`, not `/* */`. Using `//` makes it much easier to comment out a block of code while debugging.
    ```cpp
    // this function does something
    int myFunc()
    {
    }
    ```

    To comment out this function block during debugging we might do:

    ```cpp
    /*
    // this function does something
    int myFunc()
    {
    }
    */
    ```

    which would be impossible if the function comment header used `/* */`

    ### Never Use `using` In a Header File

    This causes the name space you are `using` to be pulled into the namespace of the header file.


    ### Include Guards

    Header files must contain an distinctly named include guard to avoid problems with including the same header multiple times or conflicting with other headers from other projects
    21 changes: 21 additions & 0 deletions codingstandards-2-guidelines.md
    Original file line number Diff line number Diff line change
    @@ -37,6 +37,27 @@ private:
    };
    ```
    ### Forward Declare when Possible
    This:
    ```cpp
    // some header file
    class MyClass;
    void doSomething(const MyClass &);
    ```

    instead of:

    ```cpp
    // some header file
    #include "MyClass.hpp"

    void doSomething(const MyClass &);
    ```
    This is a proactive approach to simplify compilation time and rebuilding dependencies.
    ## Performance
    ### Prefer pre-increment to post-increment
    2 changes: 2 additions & 0 deletions codingstandards-3-references.md
    Original file line number Diff line number Diff line change
    @@ -0,0 +1,2 @@
    http://geosoft.no/development/cppstyle.html

  11. lefticus revised this gist Apr 27, 2014. 1 changed file with 21 additions and 0 deletions.
    21 changes: 21 additions & 0 deletions codingstandards-1-requirements.md
    Original file line number Diff line number Diff line change
    @@ -50,6 +50,27 @@ private:
    };
    ```
    ### Distinguish C++ Files From C Files
    C++ source file should be named `.cpp` or `.cc` NOT `.c`
    C++ header files should be named `.hpp` NOT `.h`
    ### Include Guards
    Header files must contain an distinctly named include guard to avoid problems with including the same header multiple times or conflicting with other headers from other projects
    ```cpp
    #ifndef MYPROJECT_MYCLASS_HPP
    #define MYPROEJCT_MYCLASS_HPP
    namespace MyProject {
    class MyClass {
    };
    }
    #endif
    ```

    ### 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.
  12. lefticus revised this gist Apr 26, 2014. 1 changed file with 45 additions and 0 deletions.
    45 changes: 45 additions & 0 deletions codingstandards-1-requirements.md
    Original file line number Diff line number Diff line change
    @@ -4,6 +4,51 @@

    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.

    ### Descriptive and Consistent Naming

    C++ allows for arbitrary length identifier names, so there's no reason to be terse when naming variables. Use descriptive names, and be consistent in the style

    * `CamelCase`
    * `snake_case`

    are common examples. snake_case has the advantage that it can also work with spell checkers, if desired.

    #### Common C++ Naming Conventions

    * Types start with capitals: `MyClass`
    * functions and variables start with lower case: `myMethod`
    * constants are all capital: `const int PI=3.14159265358979323;`

    *Note that the C++ standard does not follow any of these guidelines. Everything in the standard is lowercase only.*

    #### Distinguish Private Object Data

    Name private data with a `m_` prefix to distinguish it from public data.

    #### Distinguish Function Parameters

    Name function parameters with an `t_` prefix.

    #### Well formed example

    ```cpp
    class MyClass
    {
    public:
    MyClass(int t_data)
    : m_data(t_data)
    {
    }

    int getData() const
    {
    return m_data;
    }

    private:
    int m_data;
    };
    ```
    ### 2 spaces indent level.
  13. lefticus revised this gist Apr 12, 2014. 3 changed files with 11 additions and 9 deletions.
    8 changes: 5 additions & 3 deletions codingstandards-0-automatedanalysis.md
    Original file line number Diff line number Diff line change
    @@ -17,28 +17,30 @@ A good combination of settings is `-Wall -Wextra -Wshadow -Wnon-virtual-dtor -pe

    ### MSVC

    MSVC has fewer warning options, so all warnings should be enabled: `/W4`
    MSVC has fewer warning options, so all warnings should be enabled: `/W4`. `/Wall` could be considered, but does not seem to be recommended even by microsoft.

    ## Static Analyzers

    Static analyzers look for errors that compilers do not look for, such as potential performance and memory issues.

    ### Cppcheck

    Cppcheck is free and opensource. It strives for 0 false positives and does a good job at it. Therefor all warning should be enabled: `-enable=all`
    [Cppcheck](http://cppcheck.sourceforge.net/) is free and opensource. It strives for 0 false positives and does a good job at it. Therefor all warning should be enabled: `-enable=all`

    ### Clang's Static Analyzer

    Clang's analyzer's default options are good for the respective platform. It can be used directly [from cmake](http://garykramlich.blogspot.com/2011/10/using-scan-build-from-clang-with-cmake.html).

    ### MSVC's Static Analyzer

    Can be enabled with the `/Analyze` command line option. For now we will stick with the default options.
    Can be enabled with the `/analyze` [command line option](http://msdn.microsoft.com/en-us/library/ms173498.aspx). For now we will stick with the default options.

    ## Code Coverage Analysis

    A coverage analysis tools shall be run when tests are executed to make sure the entire application is being tested. Unfortunately, coverage analysis requires that compiler optimizations be disabled. This can result in significantly longer test execution times.

    The most likely candidate for a coverage visualization is the [lcov](http://ltp.sourceforge.net/coverage/lcov.php) project. A secondary option is [coveralls](https://coveralls.io/), which is free for open source projects.


    ## Ignoring Warnings

    6 changes: 3 additions & 3 deletions codingstandards-1-requirements.md
    Original file line number Diff line number Diff line change
    @@ -65,10 +65,10 @@ if (x && y && myFunctionThatReturnsBool()

    ### Unit Tests

    There should be a test enabled for every feature or bug fix that is committed. See also "Code Coverage Analysis"
    There should be a test enabled for every feature or bug fix that is committed. See also "Code Coverage Analysis."

    ### Use "" For Including Local Files
    ... `<>` is reserved for system includes.
    ... `<>` is [reserved for system includes](http://blog2.emptycrate.com/content/when-use-include-verses-include).

    ```cpp
    // Bad Idea. Requires extra -I directives to the compiler
    @@ -98,7 +98,7 @@ Exceptions cannot be ignored. Return values, such as using `boost::optional`, ca

    ### 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.
    Raw memory access, allocation and deallocation, are difficult to get correct in C++ without [risking memory errors and leaks](http://blog2.emptycrate.com/content/nobody-understands-c-part-6-are-you-still-using-pointers). C++11 provides tools to avoid these problems.

    ```cpp
    // Bad Idea
    6 changes: 3 additions & 3 deletions codingstandards-2-guidelines.md
    Original file line number Diff line number Diff line change
    @@ -3,7 +3,7 @@
    ## Style

    ### Initialize Member Variables
    with the member initializer list
    ...with the member initializer list

    ```cpp
    // Bad Idea
    @@ -40,7 +40,7 @@ private:
    ## 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.
    ... when it is semantically correct. Pre-increment is [faster](http://blog2.emptycrate.com/content/why-i-faster-i-c) then post-increment because it does not require a copy of the object to be made.
    ```cpp
    // Bad Idea
    @@ -61,7 +61,7 @@ for (int i = 0; i < 15; ++i)


    ### 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.
    `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. [Here](http://kotaku.com/454293019) are some comments on const from John Carmack.

    ```cpp
    // Bad Idea
  14. lefticus revised this gist Apr 9, 2014. 1 changed file with 3 additions and 1 deletion.
    4 changes: 3 additions & 1 deletion codingstandards-1-requirements.md
    Original file line number Diff line number Diff line change
    @@ -92,7 +92,9 @@ There should be a test enabled for every feature or bug fix that is committed. S

    ## Safety

    ### Use Exceptions Instead of Return Values
    ### Use Exceptions Instead of Return Values to Indicate Error

    Exceptions cannot be ignored. Return values, such as using `boost::optional`, can be ignored and if not checked can cause crashes or memory errors. An exception, on the other hand, can be caught and handled. Potentially all the way up the highest level of the application with a log and automatic restart of the application.

    ### Avoid raw memory access

  15. lefticus revised this gist Apr 9, 2014. 1 changed file with 22 additions and 1 deletion.
    23 changes: 22 additions & 1 deletion codingstandards-1-requirements.md
    Original file line number Diff line number Diff line change
    @@ -65,9 +65,30 @@ if (x && y && myFunctionThatReturnsBool()

    ### Unit Tests

    ### <> vs ""
    There should be a test enabled for every feature or bug fix that is committed. See also "Code Coverage Analysis"

    ### Use "" For Including Local Files
    ... `<>` is reserved for system includes.

    ```cpp
    // Bad Idea. Requires extra -I directives to the compiler
    // and goes against standards
    #include <string>
    #include <includes/MyHeader.hpp>

    // Worse Idea
    // requires potentially even more specific -I directives and
    // makes code more difficult to package and distribute
    #include <string>
    #include <MyHeader.hpp>


    // Good Idea
    // requires no extra params and notifies the user that the file
    // is a local file
    #include <string>
    #include "MyHeader.hpp"
    ```

    ## Safety

  16. lefticus revised this gist Apr 9, 2014. 1 changed file with 26 additions and 1 deletion.
    27 changes: 26 additions & 1 deletion codingstandards-0-automatedanalysis.md
    Original file line number Diff line number Diff line change
    @@ -15,6 +15,31 @@ A good combination of settings is `-Wall -Wextra -Wshadow -Wnon-virtual-dtor -pe
    * `-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.

    ### MSVC

    MSVC has fewer warning options, so all warnings should be enabled: `/W4`

    ## Static Analyzers

    ## Code Coverage Analysis
    Static analyzers look for errors that compilers do not look for, such as potential performance and memory issues.

    ### Cppcheck

    Cppcheck is free and opensource. It strives for 0 false positives and does a good job at it. Therefor all warning should be enabled: `-enable=all`

    ### Clang's Static Analyzer

    Clang's analyzer's default options are good for the respective platform. It can be used directly [from cmake](http://garykramlich.blogspot.com/2011/10/using-scan-build-from-clang-with-cmake.html).

    ### MSVC's Static Analyzer

    Can be enabled with the `/Analyze` command line option. For now we will stick with the default options.

    ## Code Coverage Analysis

    A coverage analysis tools shall be run when tests are executed to make sure the entire application is being tested. Unfortunately, coverage analysis requires that compiler optimizations be disabled. This can result in significantly longer test execution times.


    ## Ignoring Warnings

    If it is determined by team consensus that the compiler or analyzer is warning on something that is either incorrect or unavoidable, the team will disable the specific error to as localized part of the code as possible.
  17. lefticus revised this gist Apr 9, 2014. 1 changed file with 13 additions and 0 deletions.
    13 changes: 13 additions & 0 deletions codingstandards-0-automatedanalysis.md
    Original file line number Diff line number Diff line change
    @@ -1,7 +1,20 @@
    # 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
  18. lefticus revised this gist Apr 9, 2014. 3 changed files with 46 additions and 17 deletions.
    7 changes: 7 additions & 0 deletions codingstandards-0-automatedanalysis.md
    Original file line number Diff line number Diff line change
    @@ -0,0 +1,7 @@
    # C++ Coding Standards Part 0: Automated Code Analysis

    ## Compilers

    ## Static Analyzers

    ## Code Coverage Analysis
    33 changes: 24 additions & 9 deletions codingstandards-1-requirements.md
    Original file line number Diff line number Diff line change
    @@ -10,6 +10,7 @@ Style guidelines are not overly strict. The important thing is that code is clea
    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.

    ```cpp
    // Good Idea
    int myFunction(bool t_b)
    {
    if (t_b)
    @@ -18,65 +19,79 @@ int myFunction(bool t_b)
    }
    }
    ```
    ### {} are required for blocks.
    Leaving them off can lead to semantic errors in the code.
    ```cpp
    // 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;
    // Correct
    // 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;
    }
    ```

    ### Keeps lines a reasonable length
    ### Keep lines a reasonable length

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

    // better
    // 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.

    ```cpp
    // bad
    // Bad Idea
    MyClass *myobj = new MyClass;

    // ...

    delete myobj;


    // Good
    // 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

    ... 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.
    23 changes: 15 additions & 8 deletions codingstandards-2-guidelines.md
    Original file line number Diff line number Diff line change
    @@ -6,7 +6,7 @@
    with the member initializer list

    ```cpp
    // bad
    // Bad Idea
    class MyClass
    {
    public:
    @@ -19,7 +19,11 @@ private:
    int m_value;
    };

    // good

    // 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:
    @@ -39,17 +43,19 @@ private:
    ... 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.
    ```cpp
    // Correct
    for (int i = 0; i < 15; ++i)
    // Bad Idea
    for (int i = 0; i < 15; i++)
    {
    std::cout << i << std::endl;
    }
    // incorrect
    for (int i = 0; i < 15; i++)
    // Good Idea
    for (int i = 0; i < 15; ++i)
    {
    std::cout << i << std::endl;
    }
    ```


    @@ -58,7 +64,7 @@ for (int i = 0; i < 15; i++)
    `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.

    ```cpp
    // bad
    // Bad Idea
    class MyClass
    {
    public:
    @@ -76,7 +82,8 @@ private:
    std::string m_value;
    }

    // good

    // Good Idea
    class MyClass
    {
    public:
  19. lefticus revised this gist Apr 9, 2014. 2 changed files with 0 additions and 0 deletions.
  20. lefticus revised this gist Apr 9, 2014. 2 changed files with 2 additions and 2 deletions.
    Original file line number Diff line number Diff line change
    @@ -1,4 +1,4 @@
    # Guidelines
    # C++ Coding Standards Part 2: Guidelines

    ## Style

    Original file line number Diff line number Diff line change
    @@ -1,4 +1,4 @@
    # Requirements
    # C++ Coding Standards Part 1: Requirements

    ## Style

  21. lefticus revised this gist Apr 9, 2014. 2 changed files with 98 additions and 98 deletions.
    98 changes: 98 additions & 0 deletions codingstandards-guidelines.md
    Original file line number Diff line number Diff line change
    @@ -0,0 +1,98 @@
    # Guidelines

    ## Style

    ### Initialize Member Variables
    with the member initializer list

    ```cpp
    // bad
    class MyClass
    {
    public:
    MyClass(int t_value)
    {
    m_value = t_value;
    }

    private:
    int m_value;
    };

    // good
    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.
    ```cpp
    // Correct
    for (int i = 0; i < 15; ++i)
    {
    std::cout << i << std::endl;
    }
    // incorrect
    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.

    ```cpp
    // bad
    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
    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;
    }
    ```
    98 changes: 0 additions & 98 deletions codingstandards.md → codingstandards-requirements.md
    Original file line number Diff line number Diff line change
    @@ -80,101 +80,3 @@ std::shared_ptr<MyClass> myobj = make_shared<MyClass>();
    this includes singleton objects


    # Good Ideas

    ## Style

    ### Initialize Member Variables
    with the member initializer list

    ```cpp
    // bad
    class MyClass
    {
    public:
    MyClass(int t_value)
    {
    m_value = t_value;
    }

    private:
    int m_value;
    };

    // good
    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.
    ```cpp
    // Correct
    for (int i = 0; i < 15; ++i)
    {
    std::cout << i << std::endl;
    }
    // incorrect
    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.

    ```cpp
    // bad
    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
    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;
    }
    ```
  22. lefticus revised this gist Apr 8, 2014. 1 changed file with 58 additions and 45 deletions.
    103 changes: 58 additions & 45 deletions codingstandards.md
    Original file line number Diff line number Diff line change
    @@ -1,9 +1,11 @@
    # Style
    # 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.
    ### 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.

    @@ -16,44 +18,7 @@ int myFunction(bool t_b)
    }
    }
    ```
    ## 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.
    ```cpp
    // bad
    MyClass *myobj = new MyClass;
    // ...
    delete myobj;
    // Good
    std::shared_ptr<MyClass> myobj = make_shared<MyClass>();
    // ...
    // myobj is automatically freed for you whenever it is no longer used.
    ```

    ## 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.

    ```cpp
    // Correct
    for (int i = 0; i < 15; ++i)
    {
    std::cout << i << std::endl;
    }

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

    ## {} are required for blocks.
    ### {} are required for blocks.
    Leaving them off can lead to semantic errors in the code.
    ```cpp
    @@ -76,7 +41,7 @@ for (int i = 0; i < 15; ++i) {
    }
    ```

    ## Keeps lines a reasonable length
    ### Keeps lines a reasonable length

    ```cpp
    // bad and hard to follow
    @@ -90,7 +55,36 @@ if (x && y && myFunctionThatReturnsBool()
    }
    ```

    ## Initialize Member Variables
    ## Safety

    ### 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.

    ```cpp
    // bad
    MyClass *myobj = new MyClass;

    // ...

    delete myobj;


    // Good
    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


    # Good Ideas

    ## Style

    ### Initialize Member Variables
    with the member initializer list

    ```cpp
    @@ -121,7 +115,28 @@ private:
    };
    ```
    ## Const as much as possible
    ## 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.
    ```cpp
    // Correct
    for (int i = 0; i < 15; ++i)
    {
    std::cout << i << std::endl;
    }
    // incorrect
    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.

    ```cpp
    @@ -163,5 +178,3 @@ private:
    ```
    ## Avoid global data
    this includes singleton objects
  23. lefticus revised this gist Apr 8, 2014. 1 changed file with 114 additions and 5 deletions.
    119 changes: 114 additions & 5 deletions codingstandards.md
    Original file line number Diff line number Diff line change
    @@ -2,9 +2,10 @@

    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.

    The only requirements are:

    * 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.
    ## 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.

    ```cpp
    int myFunction(bool t_b)
    @@ -16,7 +17,27 @@ int myFunction(bool t_b)
    }
    ```
    * 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.
    ## 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.
    ```cpp
    // bad
    MyClass *myobj = new MyClass;
    // ...
    delete myobj;
    // Good
    std::shared_ptr<MyClass> myobj = make_shared<MyClass>();
    // ...
    // myobj is automatically freed for you whenever it is no longer used.
    ```

    ## 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.

    ```cpp
    // Correct
    @@ -32,7 +53,8 @@ for (int i = 0; i < 15; i++)
    }
    ```

    * `{``}` are required for blocks. Leaving them off can lead to semantic errors in the code.
    ## {} are required for blocks.
    Leaving them off can lead to semantic errors in the code.

    ```cpp
    // this compiles and does what you want, but can lead to confusing
    @@ -54,5 +76,92 @@ for (int i = 0; i < 15; ++i) {
    }
    ```

    ## Spaces vs Tabs
    ## Keeps lines a reasonable length

    ```cpp
    // bad and hard to follow
    if (x && y && myFunctionThatReturnsBool() && caseNumber3 && (15 > 12 || 2 < 3)) {
    }

    // better
    if (x && y && myFunctionThatReturnsBool()
    && caseNumber3
    && (15 > 12 || 2 < 3)) {
    }
    ```

    ## Initialize Member Variables
    with the member initializer list

    ```cpp
    // bad
    class MyClass
    {
    public:
    MyClass(int t_value)
    {
    m_value = t_value;
    }

    private:
    int m_value;
    };

    // good
    class MyClass
    {
    public:
    MyClass(int t_value)
    : m_value(t_value)
    {
    }

    private:
    int m_value;
    };
    ```
    ## 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.
    ```cpp
    // bad
    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
    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;
    }
    ```


    ## Avoid global data
    this includes singleton objects
  24. lefticus revised this gist Apr 8, 2014. 1 changed file with 48 additions and 1 deletion.
    49 changes: 48 additions & 1 deletion codingstandards.md
    Original file line number Diff line number Diff line change
    @@ -5,7 +5,54 @@ Style guidelines are not overly strict. The important thing is that code is clea
    The only requirements are:

    * 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.
    * `{``}` are required for blocks

    ```cpp
    int myFunction(bool t_b)
    {
    if (t_b)
    {
    // do something
    }
    }
    ```
    * 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.
    ```cpp
    // Correct
    for (int i = 0; i < 15; ++i)
    {
    std::cout << i << std::endl;
    }
    // incorrect
    for (int i = 0; i < 15; i++)
    {
    std::cout << i << std::endl;
    }
    ```

    * `{``}` are required for blocks. Leaving them off can lead to semantic errors in the code.

    ```cpp
    // 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;

    // 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;

    // Correct
    int sum = 0;
    for (int i = 0; i < 15; ++i) {
    ++sum;
    std::cout << i << std::endl;
    }
    ```

    ## Spaces vs Tabs

  25. lefticus revised this gist Apr 8, 2014. 1 changed file with 10 additions and 0 deletions.
    10 changes: 10 additions & 0 deletions codingstandards.md
    Original file line number Diff line number Diff line change
    @@ -1 +1,11 @@
    # 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.

    The only requirements are:

    * 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.
    * `{``}` are required for blocks

    ## Spaces vs Tabs

  26. lefticus created this gist Apr 8, 2014.
    1 change: 1 addition & 0 deletions codingstandards.md
    Original file line number Diff line number Diff line change
    @@ -0,0 +1 @@
    # Style