How LOC are been calculated exactly

SonarQube
,
1

Dear community,
Tried to look in this forum with no luck.

How LOC are calculated in terms of additional XML files nd unit tests?

Technical information:

  • SonarQube on one EC2 instance
  • we are trying to determine how LOC are been calculated exactly
  • support 7 different development teams
2

What is the case for other non-code files who is excluded from the Sonar scan?

4

Hello @idan,

LOC counting for unit tests files
Unit tests files are not counted as LOC for the license, if they are appropriately identified as such.
With some build tools and the corresponding scanner (Scanner for Maven, Gradle, .Net) it’s generally not needed to explicitly identify test files as this is automatically deducted by the scanner.
With the SonarScanner for CLI (aka sonar-scanner), this has to be explicit, and you have to set the sonar.tests property to point at directories containing those test files… otherwise they will be considered regular source code and counted at LOC

In other words, you must set the sonar.tests property to explicitly point at directories containing unit tests, for them not to be counted as LOC.

By default (ie if you don’t specify otherwise) all XML files that are located in the directories pointed by the sonar.sources property (whose default is . meaning anything under the project root directory), is considered source code and therefore counted as LOC.

XML (and other) files counted as LOC… or not

Some XML files may be legitimate source code and you may want to analyze them as such.
However, frequently you can have XML files that are build artifacts and that you don’t want to analyze, and don’t want to consume LOC on your platform. This is by the way not limited to XML, it can also happen with JSON, CSS even Javascript (eg files minified as part of the build)

In the latter case you should exclude these files, 1) to not consume LOC and 2) to not analyze files that will produce junk reports (issues, bad metrics) in SonarQube.
To exclude these files:

  • This is typically automatic when using the Scanner for Maven, For Gradle or for .Net (because these scanners are aware of what is truly source code and what is not)
  • For the Scanner for CLI (sonar-scanner) this exclusion has to be explicit (just like explicitly pointing at tests above)
    – First you may set sonar.sources to a comma separated list of directories that exclude directories where you have these “temporary” or “unwanted” files. This is the most convenient way if the source files are XML (and the rest) unwanted files are not in the same directories
    – If the true source files and unwanted XML files are in the same directories you would have to set a 2nd property, called sonar.exclusions that will ignore unwanted (XML or otehr) files, even if they are in the same diretories as sources. For instance:
# Example 1: Pick all source files in the root directory...
sonar.sources=.
# ... and the below exclusion will exclude all XML and JSON files anywhere under the . directory
sonar.exclusions=**/*.xml, **/*.json

# Example 2: Sources to analyze are only searched in the src directory, tests are searched in the tests diretory
sonar.sources=src
sonar.tests=tests
# ...and the below will exclude, from this src directory, all files (XML or other) that have temp in the file name,
# or that are in a temp directory anywhere in the source tree,
# and all the minified JS files (assumed to follow the pattern <file>.min.js)
sonar.exclusions = **/*temp*, **/temp/**/*, **/*min.js

For more on tests and exclusions see:
https://docs.sonarqube.org/latest/project-administration/narrowing-the-focus/
https://docs.sonarqube.org/latest/analysis/analysis-parameters/

2 Likes