Commit ce2a5787 authored by GILLES Sebastien's avatar GILLES Sebastien
Browse files

Add the link to the Sonarqube presentation which adds more tools that might be used.

parent 019f6044
......@@ -109,6 +109,13 @@
"\n",
"So expect for important projects the time to generate Doxygen documentation to be bigger than compilation time.\n",
"\n",
"\n",
"## More...\n",
"\n",
"Our colleagues at Inria Bordeaux also recommend some additional tools in the SonarQ\n",
"\n",
"https://sonarqube.bordeaux.inria.fr/pages/documentation.html#orgd4ab5b1\n",
"\n",
"\n"
]
},
......
%% Cell type:markdown id: tags:
# [Getting started in C++](/) - [C++ in a real environment](/notebooks/6-InRealEnvironment/0-main.ipynb) - [External tools](/notebooks/6-InRealEnvironment/6-Tools.ipynb)
%% Cell type:markdown id: tags:
<h1>Table of contents<span class="tocSkip"></span></h1>
<div class="toc"><ul class="toc-item"><li><span><a href="#Introduction" data-toc-modified-id="Introduction-1">Introduction</a></span></li><li><span><a href="#Online-compilers" data-toc-modified-id="Online-compilers-2">Online compilers</a></span></li><li><span><a href="#Static-analyzer-tools" data-toc-modified-id="Static-analyzer-tools-3">Static analyzer tools</a></span></li><li><span><a href="#Valgrind" data-toc-modified-id="Valgrind-4">Valgrind</a></span></li><li><span><a href="#Address-sanitizer" data-toc-modified-id="Address-sanitizer-5">Address sanitizer</a></span></li><li><span><a href="#Sonarqube" data-toc-modified-id="Sonarqube-6">Sonarqube</a></span></li><li><span><a href="#Tests" data-toc-modified-id="Tests-7">Tests</a></span><ul class="toc-item"><li><span><a href="#Boost-tests" data-toc-modified-id="Boost-tests-7.1">Boost tests</a></span></li><li><span><a href="#Catch2" data-toc-modified-id="Catch2-7.2">Catch2</a></span></li><li><span><a href="#Google-test" data-toc-modified-id="Google-test-7.3">Google test</a></span></li></ul></li><li><span><a href="#Build-system" data-toc-modified-id="Build-system-8">Build system</a></span></li><li><span><a href="#Code-formatters" data-toc-modified-id="Code-formatters-9">Code formatters</a></span></li><li><span><a href="#Doxygen" data-toc-modified-id="Doxygen-10">Doxygen</a></span></li></ul></div>
%% Cell type:markdown id: tags:
## Introduction
The purpose of this notebook is just to namedrop briefly some facilities related to C++ that might be useful.
It's far from exhaustive - I won't present debuggers as usually they are provided directly with your IDE (and if you're a Vim or Emacs user you probably already familiar with [gdb](https://www.gnu.org/software/gdb/)).
Some tools are redundant, but they are complementary: the more you may be able to use the better. The constraint is time: it is not straightforward to use some of those, and even for the user-friendly ones there is a non neglictible set-up time. But for projects that are gaining traction it becomes a no-brainer at some point to set-up those properly once and for all - usually part of [continuous integration](https://gitlab.inria.fr/FormationIntegrationContinue/gitlabciintroduction) process.
## Online compilers
This [blog post](https://arne-mertz.de/2017/05/online-compilers/) gives several such online compilers we mentioned several times in this tutorial.
I have used only [Coliru](http://coliru.stacked-crooked.com/) which provides an API to incorporate directly some interactive code in a Web page (disclaimer - I have not used that feature yet) and [Wandbox](http://melpon.org/wandbox) which may be useful in day-to-day work as you may try a snippet of code with many configurations. It's useful for instance when you intend to use a bleeding-edge feature to see which version of compilers support it or not.
## Static analyzer tools
[cppcheck](http://cppcheck.sourceforge.net/) is a static analyser program; it might really help you to find some questionable constructs in your code. As many tools, it's not 100 % accurate and sometimes it may raise false positives, but I nonetheless recommend it warmly.
[cpplint](https://github.com/cpplint/cpplint) is also worth a look, we mentioned it for instance in [this chapter](/notebooks/6-InRealEnvironment/2-FileStructure.ipynb) to track down missing includes in files.
[clang-tidy](https://clang.llvm.org/extra/clang-tidy/) was recently recommanded to us by colleagues from [LoOPS network](https://reseau-loops.github.io/index.html).
## Valgrind
[Valgrind](valgrind.org/) is mostly known as a leak checker, but is really a jack-of-all-trade tool; callgrind for instance may be used to profile your code and see where most of the computation time is spent. Some lesser-known tools are also incredibly useful: [Verrou](https://github.com/edf-hpc/verrou) for instance, developed at EDF, is a floating-point checker which helps you figure out if at some point some of your computations might be skewed by the way the computer approximates the real numbers.
Unfortunately, macOS support is scarse: sometimes they plainly say it is not up-to-date, but even they say ot works the outputs were never satisfactory for me. So even if I develop mostly in macOS I always fire up valgrind in a Linux environment.
## Address sanitizer
A [recent "concurrent"](https://github.com/google/sanitizers/wiki/AddressSanitizer) (once again use both if possible!) to Valgrind, which has the advantage of running with a much better runtime (Valgrind slows down your program tremendously). Might be integrated in some IDEs (it is in XCode on macOS).
## Sonarqube
[Sonarqube](https://www.sonarqube.org/) is a development platform which inspects your code and helps to figure out where there are issues. It enables integration of multiple tools such as cppcheck mentioned earlier. If you're Inria staff, an instance was set by our [Bordeaux colleagues](https://sonarqube.bordeaux.inria.fr/) and is available for you.
For open-source projects, the company behind Sonarqube provides a [freely accessible platform]( https://sonarcloud.io/about).
## Tests
These are frameworks to write your tests; to actually run them you should see what your build system provides (for instance CMake comes with CTest which takes gracefully the management of tests in your project).
### Boost tests
[Boost test](https://www.boost.org/doc/libs/1_69_0/libs/test/doc/html/index.html) is a widely used facility to write unit and integration tests with your code.
It might be used as a header-only or as a compiled library; for big projects they recommend using the latter.
### Catch2
[Catch2](https://github.com/catchorg/Catch2) is a more recent test facility which is aimed at being user-friendly. I'm using it but currently regret they do not for the time being provide a test to check a test ends-up with an abortion, which is something Boost Test is able to do. So even if I'm happy enough with it not to rewrite my tests in Boost Test I would recommend Boost over it for now.
### Google test
This test utility is the only one we know that provide mocks; unfortunately I can't give you first-hand feedback.
## Build system
Already mentioned [here](/notebooks/6-InRealEnvironment/1-SetUpEnvironment.ipynb#Build-system).
## Code formatters
It is useful to delegate the check on your code format to an external tool, which may take a bit of time to configurate to suit your needs.
I can mention [Uncrustify](http://uncrustify.sourceforge.net/): plenty of options to configure, even if they're not easy to figure out.
[clang-format](https://clang.llvm.org/docs/ClangFormat.html) probably provides a better trade-off power/complexity but requires clang to be installed on your system.
## Doxygen
[Doxygen](www.doxygen.nl/) is a software to write an automatic documentation for your functions / classes / types / you name it.
It is rather easy to set up to easy task but may become a tad more difficult once you want to tackle more advanced features. Nonetheless it is the de-facto standard for C++ documentation and it's really something you should set up quite early if you're working on a project meant to stay for a while: it's really a hassle to spend countless hours providing after the fact such guidance in the code. As for compilers, you should strive to provide a documentation without any warning.
An important drawback of Doxygen is that its "compilation" of your project is much less advanced than the one provided by your compiler:
* No parallelism in some steps.
* Everything is redone at each Doxygen call.
So expect for important projects the time to generate Doxygen documentation to be bigger than compilation time.
## More...
Our colleagues at Inria Bordeaux also recommend some additional tools in the SonarQ
https://sonarqube.bordeaux.inria.fr/pages/documentation.html#orgd4ab5b1
%% Cell type:markdown id: tags:
© _CNRS 2016_ - _Inria 2018-2019_
_This notebook is an adaptation of a lecture prepared and redacted by David Chamont (CNRS) under the terms of the licence [Attribution-NonCommercial-ShareAlike 4.0 International (CC BY-NC-SA 4.0)](http://creativecommons.org/licenses/by-nc-sa/4.0/)_
_The present version has been redacted by Sébastien Gilles and Vincent Rouvreau (Inria)_
......
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment