How many parsing errors are acceptable to get good technical debt results?

[guwirth]

Using sonar.cxx.includeDirectories and sonar.cxx.forceIncludes in the right way results in less parsing errors.

On the other hand analyzing time is increased because of these additional includes. During performance test I found: Most important part is how many and complex includes exist. For example integration of complex boost slow down things.

In my case resulting technical debt was with and without these includes always the same. So wondering if it would not be better not to add system includes and external libraries?

What is your experience?

[wenns]

Just a side node: to get good technical debt results in presence of 'parsing error' violations the remediation costs of the latter should be probably set to 'zero'. Otherwise we're charging technical debt of the codebase with technical debt of projects setup and our grammar ;)

[jmecosta]

characteristics for parsing error have not been defined, so we are cleared

[guwirth]

My conclusion: As long as only external tools are used and not the checks based on the AST, parsing errors doesn't matter. Also sonar.cxx.includeDirectories and sonar.cxx.forceIncludes are not needed for this case. Not setting them will reduce analysis time.

[guwirth]

See also discussion in #237 and comment of @wenns.

We already use it for a couple metrics and we will use it even more. The AST matters.

I'm not sure if this is the right way or we should not better rely on
external tools. Looking to the current checks they are all very special
or existing static code analyzes are doing the same.

Im actually not talking about the builtin checks, but all features which
are based on the AST. This includes most of the size-like metrics
(#locs, #statments/classes/methods), complexity, custom XPath rules,
design metrics, public API detection etc.

And more is coming: all the cartography-stuff which from SonarSource's
roadmap requires an accurate program model which in turn has to build
upon the AST.

Parsing and building the AST doesnt end in itself, it enables many
things, many of which we get 'for free' through the usage of the SQ
platform or SQ libs. When the goal is to achieve accurate measures, an
accurate and 'high quality' AST is a precondition. Or at least I believe
so. The 'just get it all parsed'-goal is probably somewhat short
sighted, a point may come when we will be thinking about the
size/shape/'quality' of our AST...

[jmecosta]

@guwirth seems we all agree parser errors should not produce technical debt. This need to be changed before release