What is easiest to use static C++ code analyser?

[Szyk Cech]

Hello!

I want follow advises of great book: "Testen in Scrum-Projekten" by Tilo
Linz. One of his advises which I consider easy to make is use static
code analyser to check if programmers respect coding rules.

I am looking for C++ code analyser but I am interested with such tool
for Java Script or Bash also.

I found great wiki page with list of most popular static code analysers:

https://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis

but I have no time to try all of them.
So maybe you have some experience with those tools if so:
Please answer me to question:

What is easiest to use static C++ code analyser?

Thak you in advance and best regards!
Szyk Cech

[David Brown]

This will depend on your needs, and your budget.

Tools like Coverity, Klocwork and PVS-Studio are all powerful and well
regarded, but can cost quite a lot of money. This kind of tool will
often run on a server and produce detailed reports.

At the other end of the scale, there are lots of free and open source
analysers. You can come a long way with the warnings found in good
compilers like gcc, clang and MSVC, and can make good use of static
assertions in your code. (gcc and clang also have a selection of
run-time checking sanitizers.) Lightweight but helpful analysers like
cppcheck can be integrated with an IDE - they don't spot as many errors,
but what they do find, they identify as early as possible.

There are also lots of specialised tools for particular purposes, such
as "Sparse" for spotting certain faults in the Linux kernel.

If you decide to use a tool beyond your compiler's warnings, there are a
couple of things to watch out for. One is that static analysers are
often behind compilers in support for newer features and standards, and
certainly for any compiler-specific extensions. That may limit your
coding styles. The other is that they often need additional information
in order to do more analysis - for many, this is done using comments in
particular formats. It is quite possible to end up with code where
these special comments make it difficult to find and read the real code
- if they distract from the readability of the code, they are
counter-productive.

My recommendation is to start with the features provided in the compiler
you are using - read the manual page for the warnings, and try them (not
all will suit your programming style). And use a good IDE with cppcheck
or similar built in. Only move on when you have outgrown these and are
willing to spent some time and/or money on the matter.

[Ian Collins]

We use two, Cppcheck and clang-tidy.

Cppcheck is reasonably fast, so we run it on every build. It spots a
good number of problems, it categories issues as Error, Warning, Style,
Performance, Portability and Information. You can filter based on
category or specific warning.

clang-tidy is much slower (we run it as a separate job) because it digs
much deeper into the code and can follow control flow paths. It has an
extensive list of warnings, many of which can be automatically repaired.
See <http://clang.llvm.org/extra/clang-tidy/index.html#using-clang-tidy>

Both can be run in parallel, which speed things along if you have the
hardware.

HTH,

--
Ian.

[Richard]

[Please do not mail me a copy of your followup]

Szyk Cech <szyk...@spoko.pl> spake the secret code
<hfz7F.36165$Xs5....@fx06.am4> thusly:

>What is easiest to use static C++ code analyser?

Probably the easiest one to use is the one built into your C++
compiler.

Clang: <https://clang-analyzer.llvm.org/>
MSVC: /analyze
<https://docs.microsoft.com/en-us/cpp/build/reference/analyze-code-analysis?view=vs-2019>
gcc probably has something but nothing is turning up at the moment.

Outside of the compiler, I have used cppcheck and it's easy to run
outside of a build. <http://cppcheck.sourceforge.net/>

The general advice is to run as many static analyzer tools as you can
because they all have strengths and weaknesses and they haven't yet
converged to have huge overlap, although there is some overlap.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

[Richard]

[Please do not mail me a copy of your followup]

r...@zedat.fu-berlin.de (Stefan Ram) spake the secret code
<code-analyzer-...@ram.dialup.fu-berlin.de> thusly:

>Szyk Cech <szyk...@spoko.pl> writes:
>>What is easiest to use static C++ code analyser?
>

> Every static code analyzer is easy to use
> (unless you want to use it under Windows).

Lies.

[Jorgen Grahn]

The compiler itself -- the warnings which aren't enabled by default
but make sense anyway.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[Jens Kallup]

Hello,

if you would like to write your own text
analyze tool(s), I point you to have a look
over the compiler-compiler tool "bison",
and "flex", and yacc.

bison, flex, and yacc are available under
GPL licensed Open Source Code for most all
operating system's (Linux, Windows, MacOS).

Them the tool(s) can be download for C/C++,
Pascal/Delphi, Lazarus, etc...

Hope This Helps

Jens

[Richard]

[Please do not mail me a copy of your followup]

Jens Kallup <jka...@web.de> spake the secret code
<qk617q$72c$1...@news.albasani.net> thusly:

>if you would like to write your own text
>analyze tool(s), I point you to have a look
>over the compiler-compiler tool "bison",
>and "flex", and yacc.

Sorry, but this is a HORRIBLE idea for parsing C++ code.

If you want to write your own code analysis tools, use the clang
libraries.

[Jorgen Grahn]

On Wed, 2019-08-28, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> Jens Kallup <jka...@web.de> spake the secret code
> <qk617q$72c$1...@news.albasani.net> thusly:
>
>>if you would like to write your own text
>>analyze tool(s), I point you to have a look
>>over the compiler-compiler tool "bison",
>>and "flex", and yacc.
>
> Sorry, but this is a HORRIBLE idea for parsing C++ code.
>
> If you want to write your own code analysis tools, use the clang
> libraries.

There's also no indication whatsoever that the OP wanted to write the
tools himself -- he (understandably) didn't even want to evaluate the
ones which already are available to him.

[Richard]

[Please do not mail me a copy of your followup]

Jorgen Grahn <grahn...@snipabacken.se> spake the secret code
<slrnqmdl3j.c...@frailea.sa.invalid> thusly:

I agree, but suggesting that one use lex/yacc for parsing C++ is an
approach that many people have tried and failed. It's a really awful
idea. That suggestion should not be left out in the open
unchallenged.

This is particularly true when you can just use the clang libraries to
get a perfectly conforming C++20 parser that will just hand you an
AST.

[David Brown]

Another option that would be interesting for static analysis is a gcc
plugin, possibly written in a different language (Python is a reasonable
choice for such tasks).

I can't tell you whether clang or gcc would be the best starting point
for making your own static analysis tools, but I look at both of them
/long/ before looking at lex/yacc.

[Jorgen Grahn]

On Wed, 2019-08-28, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> Jorgen Grahn <grahn...@snipabacken.se> spake the secret code
> <slrnqmdl3j.c...@frailea.sa.invalid> thusly:
>
>>On Wed, 2019-08-28, Richard wrote:
>>> [Please do not mail me a copy of your followup]
>>>
>>> Jens Kallup <jka...@web.de> spake the secret code
>>> <qk617q$72c$1...@news.albasani.net> thusly:
>>>
>>>>if you would like to write your own text
>>>>analyze tool(s), I point you to have a look
>>>>over the compiler-compiler tool "bison",
>>>>and "flex", and yacc.
>>>
>>> Sorry, but this is a HORRIBLE idea for parsing C++ code.
>>>
>>> If you want to write your own code analysis tools, use the clang
>>> libraries.
>>
>>There's also no indication whatsoever that the OP wanted to write the
>>tools himself -- he (understandably) didn't even want to evaluate the
>>ones which already are available to him.
>
> I agree, but suggesting that one use lex/yacc for parsing C++ is an
> approach that many people have tried and failed. It's a really awful
> idea. That suggestion should not be left out in the open
> unchallenged.

Yes, that was also worth pointing out, for other readers.

[Richard]

[Please do not mail me a copy of your followup]

David Brown <david...@hesbynett.no> spake the secret code
<qk6nnl$nh0$1...@dont-email.me> thusly:

>On 28/08/2019 22:00, Richard wrote:
>> I agree, but suggesting that one use lex/yacc for parsing C++ is an
>> approach that many people have tried and failed. It's a really awful
>> idea. That suggestion should not be left out in the open
>> unchallenged.
>>
>> This is particularly true when you can just use the clang libraries to
>> get a perfectly conforming C++20 parser that will just hand you an
>> AST.
>>

>Another option that would be interesting for static analysis is a gcc
>plugin, possibly written in a different language (Python is a reasonable
>choice for such tasks).

Bwuahahahahaha! That is hilarious. Seriously. I know they've
improved gcc at this point, but Stallman et al. have literally said
that they made the internal interface as painful as possible to put
into a library on purpose because they didn't want anyone doing that.

Clang was designed from the ground up to be used as a library.

>I can't tell you whether clang or gcc would be the best starting point
>for making your own static analysis tools, but I look at both of them
>/long/ before looking at lex/yacc.

Don't bother looking at lex/yacc because the context-sensitive nature
of many C++ constructs makes it impossible to use lex/yacc.

Don't waste your time with GCC because it isn't designed to be used
this way.

Go straight to clang because that's what it's been designed for.

[David Brown]

On 03/09/2019 22:17, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> David Brown <david...@hesbynett.no> spake the secret code
> <qk6nnl$nh0$1...@dont-email.me> thusly:
>
>> On 28/08/2019 22:00, Richard wrote:
>>> I agree, but suggesting that one use lex/yacc for parsing C++ is an
>>> approach that many people have tried and failed. It's a really awful
>>> idea. That suggestion should not be left out in the open
>>> unchallenged.
>>>
>>> This is particularly true when you can just use the clang libraries to
>>> get a perfectly conforming C++20 parser that will just hand you an
>>> AST.
>>>
>
>> Another option that would be interesting for static analysis is a gcc
>> plugin, possibly written in a different language (Python is a reasonable
>> choice for such tasks).
>
> Bwuahahahahaha! That is hilarious. Seriously. I know they've
> improved gcc at this point, but Stallman et al. have literally said
> that they made the internal interface as painful as possible to put
> into a library on purpose because they didn't want anyone doing that.
>

That was certainly true. But it is a long time - a very long time -
since Stallman and others with that attitude have ruled gcc. There is
no doubt that Stallman specifically wanted strong ties between different
parts of the code in gcc, to make it as difficult as possible to split
it up and mix the gcc front ends with commercial or closed backends, or
vice versa. However, as the project grew, with many more people
involved, many front ends, and many back ends, it got steadily cleaner
separation and more modularisation. And with gcc 4.5, nearly 10 years
ago (IIRC), it got plugin support.

One of the big influences and motivations for gcc plugins is the
competitive / cooperative relationship with llvm/clang. The two
projects push each other forward, which is great for users of either
tool suite.

RMS may not like the fact that gcc has plugins, with the risk that has
of mixing closed source software with gcc, but there is no doubt that
gcc supports plugins and these are used, amongst other things, for
additional static analysis.

> Clang was designed from the ground up to be used as a library.
>

True.

>> I can't tell you whether clang or gcc would be the best starting point
>> for making your own static analysis tools, but I look at both of them
>> /long/ before looking at lex/yacc.
>
> Don't bother looking at lex/yacc because the context-sensitive nature
> of many C++ constructs makes it impossible to use lex/yacc.
>

True.

> Don't waste your time with GCC because it isn't designed to be used
> this way.

Unless you are stuck a decade behind the times, /do/ look at gcc, and
especially the existing plugin libraries, if you want to make your own
static analysis. And look at clang. Compare their approaches, compare
the documentation, websites, blogs, tutorials, third-party code,
examples and other information. Then figure out what is going to make
sense for the kind of tool you want to make and use.

My guess - and it is only a guess - is that clang is going to be the
best base if you want to write a large-scale checker and you want high
speed for analysing large code bases. And gcc with the Python or Melt
(Lisp) plugins are going to be good for small-scale checks written in
higher level languages.

[Bonita Montero]

The best code analyzer is: printing the code out, having a bath
with the printouts in the hand or lying in the bad with the code
in the hand and a purring cat beside.