newSignificantCode API


I like to understand the usage of newSignificantCode API (

As far as I understood there is already CoreMetrics.NCLOC_DATA_KEY and CoreMetrics.EXECUTABLE_LINES_DATA_KEY which must be set in FileLinesContext.

NewCode should anyway be detected for EXECUTABLE_LINES_DATA_KEY only? So what is the benefit of newSignificantCode?

SQ 7.9 seems to detect NewCode also for comments and empty lines. Will this be improved in next LTS?


Hi @guwirth,

Like most other methods on SensorContext, newXXX prefix is a convention that only means this is a builder. Nothing to do with the “new code” period.
SignificantCode concept allows to ignore some part of the code when doing the issue tracking between consecutive analysis. It was introduced for legacy languages like Cobol, because the code could look like:

0002   DO xxx
0003 END

then if the user change the code for the next analysis, it may look like:

0002  IF XXX
0003   DO xxx
0004 END

You can see that the 4 first columns are automatically generated and equal to the line number. It is better to ignore them when doing the diff, else all lines are considered as changed.

Hi @Julien_HENRY,

thanks for your answer.

Builder to declare which parts of the code is significant code. Ranges that are not reported as significant code will be ignored and won’t be considered when calculating which lines were modified. If the significant code is not reported for a file, it is assumed that the entire file is significant code.

I understood will be ignored and won't be considered ... which lines were modified as are ignored calculating NewCode? Currently with SQ 7.9 also comments and empty new lines are marked new.

My idea was to mark ranges which are EXECUTABLE_LINES_DATA also newSignificantCode to exclude all other parts from being New Code.

Maybe I’m on the wrong track? My understanding is that newSignificantCode excludes modified code lines from recalculating the hash value to detect new code?


If I’m correct, the “new code” concept in SQ includes comments, by design. IMO this is consistent with the fact SQ can raise issues on comments.

Executable lines are something different than NCLOC. This is to identify lines that can technically be covered by unit tests. For example, an import statement count in NCLOC, but not in executable lines.

I advice you to not use the significantCode API except if you are in the scenario I mentioned (legacy language with fixed format where some columns should be totally ignored). If you “abuse” the API, there could be some unexpected consequences on metric computation, and things working today may suddenly stop working in a later release.

Hi @Julien_HENRY , thx for your advise.