Static code analysis: integrate into debug and release builds, or just one or the other?

Question

As a best practice, do you run code analysis on both debug and release builds, or just one or the other?

What do you mean by debug and release builds? The code should be the same... — Thomas Owens, Sep 01 '09 at 15:29
In .Net, if you use the Conditional output extensively, you could be producing slightly different builds. — Austin Salonen, Sep 01 '09 at 15:33

score 2 · Answer 1 · answered Sep 01 '09 at 15:32

2

If for some reason the two builds are different (and they really shouldn't be for static analysis purposes), you should ensure that your metrics are running against what's actually going out to production.

Ideally, you should have a CI server, and the commands that developers run to initiate such analysis are no different from what the CI server does.

answered Sep 01 '09 at 15:32

John Feminella

303,634
46
339
357

Yep. The idea is to integrate the code analysis into the CI environment. – Scott Marlowe Sep 01 '09 at 15:55

score 1 · Accepted Answer · answered Sep 01 '09 at 15:30

1

I usually pick one and that one is the release build. I guess it doesn't really matter but I tend to think that when gather information about what will run in production it is best to test exactly what will go to production (this goes for analysis, profiling, benchmarking, etc.).

answered Sep 01 '09 at 15:30

Andrew Hare

344,730
71
640
635

So in your project's build config, do you define CODE_ANALYSIS in the release build? Does that change the release build's output significantly or affect performance? – slolife Oct 08 '10 at 23:29

score 1 · Answer 3 · answered Sep 01 '09 at 15:30

1

Static Code Analysis will show the same results regardless of your build type.

Debug/Release only changes the resulting assembly and the inclusion or exclusion of debugging information at runtime.

answered Sep 01 '09 at 15:30

Mitchel Sellers

62,228
14
110
173

right. and I guess you wouldn't care about the analysis of debug only code. makes sense. – Scott Marlowe Sep 01 '09 at 15:31
This isn't completely true, a debug build will not be optimized by the compiler and may emit IL that will not be in a optimized release build. – Andrew Hare Sep 01 '09 at 15:33
@Andrew - True, I guess depending on how/where in the process the tool evaluates there could be some inlining and other optimizations that work in to release only builds. – Mitchel Sellers Sep 01 '09 at 17:29

score 1 · Answer 4 · edited May 23 '17 at 11:58

1

I don't have separate ‘debug’ and ‘release’ builds (see Separate ‘debug’ and ‘release’ builds?).

edited May 23 '17 at 11:58

Community

1
1

answered Sep 01 '09 at 15:31

ChrisW

54,973
13
116
224

score 0 · Answer 5 · answered Jun 06 '16 at 17:14

The LLVM folks actually recommend analyzing the DEBUG configuraion:

ALWAYS analyze a project in its "debug" configuration

Most projects can be built in a "debug" mode that enables assertions. Assertions are picked up by the static analyzer to prune infeasible paths, which in some cases can greatly reduce the number of false positives (bogus error reports) emitted by the tool.

In addition, debug builds tend to be faster (no need for optimization), and in the CI world faster is always better (all else being equal).

Static code analysis: integrate into debug and release builds, or just one or the other?

5 Answers5