mirror of
https://github.com/cpp-best-practices/cppbestpractices.git
synced 2025-12-17 03:04:36 +03:00
Small improvements, cleanup
This commit is contained in:
Alex Swindler
@@ -6,23 +6,23 @@ An automated framework for executing these tools should be established very earl
|
||||
|
||||
Source control is an absolute necessity for any software development project. If you are not using one yet, start using one.
|
||||
|
||||
* [github](http://github.com) - allows for unlimited public repositories, must pay for a private repository
|
||||
* [bitbucket](http://bitbucket.org) - allows for unlimited private repositories with up to 5 collaborators, for free.
|
||||
* [sourceforge](http://sf.net) - open source hosting only
|
||||
* [GitLab](https://gitlab.com/), Subversion, Bitkeeper, many many others... The above are the most popular free services.
|
||||
* [GitHub](https://github.com/) - allows for unlimited public repositories, must pay for a private repository.
|
||||
* [Bitbucket](https://bitbucket.org/) - allows for unlimited private repositories with up to 5 collaborators, for free.
|
||||
* [SourceForge](http://sourceforge.net/) - open source hosting only.
|
||||
* [GitLab](https://gitlab.com/), Subversion, BitKeeper, many many others... The above are the most popular free services.
|
||||
|
||||
## Build Tool
|
||||
|
||||
Use an industry standard widely accepted build tool. This prevents you from reinventing the wheel whenever you discover / link to a new library / package your product / etc. Examples include:
|
||||
|
||||
* [cmake](http://cmake.org)
|
||||
* [biicode](http://biicode.com)
|
||||
* [waf](https://waf.io/)
|
||||
* [CMake](http://www.cmake.org/)
|
||||
* [Biicode](https://www.biicode.com/)
|
||||
* [Waf](https://waf.io/)
|
||||
* [FASTBuild](http://www.fastbuild.org/)
|
||||
* [ninja](https://martine.github.io/ninja/) - can greatly improve the incremental build time of your larger projects. Can be used as a target for cmake
|
||||
* google's build tool
|
||||
* [Ninja](https://martine.github.io/ninja/) - can greatly improve the incremental build time of your larger projects. Can be used as a target for CMake.
|
||||
* [Bazel](http://bazel.io/)
|
||||
|
||||
Remember, it's not just a build tool, it's also a programming language. Try to maintain good clean build scripts and follow the recommended practices for the tool you are using
|
||||
Remember, it's not just a build tool, it's also a programming language. Try to maintain good clean build scripts and follow the recommended practices for the tool you are using.
|
||||
|
||||
## Continuous Integration
|
||||
|
||||
@@ -32,16 +32,17 @@ Continuous Integration (CI) tools automatically build the source code as changes
|
||||
|
||||
* [Travis CI](http://travis-ci.org)
|
||||
* works well with C++
|
||||
* designed for use with github
|
||||
* free for public repositories on github
|
||||
* Hudson CI
|
||||
* Appveyor
|
||||
* designed for use with GitHub
|
||||
* free for public repositories on GitHub
|
||||
* [Hudson CI](http://hudson-ci.org/)
|
||||
* [AppVeyor](http://www.appveyor.com/)
|
||||
* supports Windows and MSVC
|
||||
* [Decent CI](https://github.com/lefticus/decent_ci)
|
||||
* simple ad-hoc continuous integration that posts results to github
|
||||
* supports Windows, MacOS and Linux
|
||||
* simple ad-hoc continuous integration that posts results to GitHub
|
||||
* supports Windows, OS X, and Linux
|
||||
* used by [ChaiScript](http://chaiscript.com/ChaiScript-BuildResults/full_dashboard.html)
|
||||
|
||||
If you have an OpenSource, publicly hosted project on github, go enable travis-ci integration right now. We'll wait for you to come back. For a simple example of how to enable it for your C++ CMake based application, see here: https://github.com/ChaiScript/ChaiScript/blob/master/.travis.yml
|
||||
If you have an open source, publicly-hosted project on GitHub, go enable travis-ci integration right now. We'll wait for you to come back. For a simple example of how to enable it for your C++ CMake-based application, see here: https://github.com/ChaiScript/ChaiScript/blob/master/.travis.yml
|
||||
|
||||
|
||||
## Compilers
|
||||
@@ -58,7 +59,7 @@ You should use as many compilers as you can for your platform(s). Each compiler
|
||||
* `-Wshadow` warn the user if a variable declaration shadows one from a parent context
|
||||
* `-Wnon-virtual-dtor` warn the user if a class with virtual functions has a non-virtual destructor. This helps catch hard to track down memory errors
|
||||
* `-Wold-style-cast` warn for c-style casts
|
||||
* `-Wcast-align` warn for potential performance problem casts
|
||||
* `-Wcast-align` warn for potential performance problem casts
|
||||
* `-Wunused` warn on anything being unused
|
||||
* `-Woverloaded-virtual` warn if you overload (not override) a virtual function
|
||||
* `-pedantic`
|
||||
@@ -74,37 +75,33 @@ You should use as many compilers as you can for your platform(s). Each compiler
|
||||
|
||||
Not recommended
|
||||
|
||||
* `/Wall` - Also warns on files included from the standard library, so it's not very useful and creates too many extra warnings.
|
||||
* `/Wall` - Also warns on files included from the standard library, so it's not very useful and creates too many extra warnings.
|
||||
|
||||
|
||||
|
||||
### General
|
||||
|
||||
Start with very strict warnings settings from the beginning. Trying to raise the warning level after the project is underway can be painful.
|
||||
Start with very strict warning settings from the beginning. Trying to raise the warning level after the project is underway can be painful.
|
||||
|
||||
Consider using the "treat warnings as errors" setting. `/Wx` with MSVC, `-Werror` with GCC / Clang
|
||||
Consider using the *treat warnings as errors* setting. `/Wx` with MSVC, `-Werror` with GCC / Clang
|
||||
|
||||
## llvm based tools
|
||||
## LLVM-based tools
|
||||
|
||||
|
||||
include-what-you-use https://github.com/ChaiScript/ChaiScript/commit/c0bf6ee99dac14a19530179874f6c95255fde173
|
||||
|
||||
clang-modernize https://github.com/ChaiScript/ChaiScript/commit/6eab8ddfe154a4ebbe956a5165b390ee700fae1b
|
||||
|
||||
clang-check
|
||||
clang-tidy
|
||||
* [include-what-you-use](https://code.google.com/p/include-what-you-use/), [example results](https://github.com/ChaiScript/ChaiScript/commit/c0bf6ee99dac14a19530179874f6c95255fde173)
|
||||
* [clang-modernize](http://clang.llvm.org/extra/clang-modernize.html), [example results](https://github.com/ChaiScript/ChaiScript/commit/6eab8ddfe154a4ebbe956a5165b390ee700fae1b)
|
||||
* [clang-check](http://clang.llvm.org/docs/ClangCheck.html)
|
||||
* [clang-tidy](http://clang.llvm.org/extra/clang-tidy.html)
|
||||
|
||||
## Static Analyzers
|
||||
|
||||
The best bet is the static analyzer that you can run as part of your automated build system. cppcheck and clang meet that requirement for free options.
|
||||
The best bet is the static analyzer that you can run as part of your automated build system. Cppcheck and clang meet that requirement for free options.
|
||||
|
||||
### cppcheck
|
||||
Cppcheck is free and opensource. It strives for 0 false positives and does a good job at it. Therefore all warnings should be enabled: `-enable=all`
|
||||
### Cppcheck
|
||||
Cppcheck is free and open source. It strives for 0 false positives and does a good job at it. Therefore all warnings 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). They can also be called via clang-check and clang-tidy from the LLVM Based Tools.
|
||||
|
||||
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). They can also be called via clang-check and clang-tidy from the [LLVM-based Tools](#llvm-based-tools).
|
||||
|
||||
### MSVC's Static Analyzer
|
||||
|
||||
@@ -112,11 +109,11 @@ Can be enabled with the `/analyze` [command line option](http://msdn.microsoft.c
|
||||
|
||||
### ReSharper C++ / CLion
|
||||
|
||||
Both of these tools from [JetBrains](https://www.jetbrains.com/cpp/) offer some level of static analysis and automated fixes for common things that can be done better. They have options available for free licenses for Open Source project leaders.
|
||||
Both of these tools from [JetBrains](https://www.jetbrains.com/cpp/) offer some level of static analysis and automated fixes for common things that can be done better. They have options available for free licenses for open source project leaders.
|
||||
|
||||
### Qt Creator
|
||||
|
||||
Qt Creator can plug into the clang static analyzer, but *only* on the *commercial* version of Qt Creator.
|
||||
Qt Creator can plug into the clang static analyzer, but *only* on the *commercial* version of Qt Creator.
|
||||
|
||||
### Metrix++
|
||||
|
||||
@@ -130,22 +127,22 @@ While not necessarily a static analyzer, Metrix++ can identify and report on the
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
An alternative to lcov is [gcovr](http://gcovr.com/). It seems to provide similar functionality, but is written in python.
|
||||
<link to chaiscript example of using it>
|
||||
An alternative to LCOV is [Gcovr](http://gcovr.com/). It seems to provide similar functionality, but is written in Python.
|
||||
<link to ChaiScript example of using it>
|
||||
|
||||
### Valgrind
|
||||
|
||||
Runtime code analyzer that can detect memory leaks, race conditions and other associated problems. It is supported on various unix platforms.
|
||||
Runtime code analyzer that can detect memory leaks, race conditions, and other associated problems. It is supported on various Unix platforms.
|
||||
|
||||
### GCC/Clang Sanitizers
|
||||
### GCC / Clang Sanitizers
|
||||
|
||||
These tools provide many of the same features as valgrind, but built into the compiler. They are easy to use and provide a report of what went wrong.
|
||||
These tools provide many of the same features as Valgrind, but built into the compiler. They are easy to use and provide a report of what went wrong.
|
||||
|
||||
* address
|
||||
* thread
|
||||
* undefined
|
||||
* AddressSanitizer
|
||||
* ThreadSanitizer
|
||||
* UndefinedBehaviorSanitizer
|
||||
|
||||
|
||||
## Ignoring Warnings
|
||||
@@ -156,7 +153,7 @@ If it is determined by team consensus that the compiler or analyzer is warning o
|
||||
|
||||
CMake, mentioned above, has a built in framework for executing tests. Make sure whatever build system you use has a way to execute tests built in.
|
||||
|
||||
To further aid in executing tests, consider a library such as [googletest](https://code.google.com/p/googletest/) or [Catch](https://github.com/philsquared/Catch) to help you organize the tests.
|
||||
To further aid in executing tests, consider a library such as [Google Test](https://code.google.com/p/googletest/) or [Catch](https://github.com/philsquared/Catch) to help you organize the tests.
|
||||
|
||||
### Unit Tests
|
||||
|
||||
@@ -164,7 +161,7 @@ Unit tests are for small chunks of code, individual functions which can be teste
|
||||
|
||||
### Integration Tests
|
||||
|
||||
There should be a test enabled for every feature or bug fix that is committed. See also "Code Coverage Analysis." These are tests that are higher level than unit tests. They should still be limited in scope to individual features.
|
||||
There should be a test enabled for every feature or bug fix that is committed. See also [Code Coverage Analysis](#code-coverage-analysis). These are tests that are higher level than unit tests. They should still be limited in scope to individual features.
|
||||
|
||||
### Negative Testing
|
||||
|
||||
|
||||
Reference in New Issue
Block a user