Lines of code limit problem (production license)

Company i work for has “production” license with 250k lines of code limit. Currently there are 9 project scanned and 10nth just arrived and caused “limit error”. But …
From what i calculated manually (by summarizing digits on the right side of each project) those 9 projects give arround 144k lines of code.

On the license panel i actually see that actual value is much more
image

Its very unlikely that this one project added arround 93k lines of code to even meet the value. But error indicates that LOC value is much higher …

So my questions:

  1. How this limit is calculated. Is it summary of each projects largest branch or not?
  2. What are those values on the right side of each project summary?
  3. How lines are actually counted. I mean, those projects use C/C++. I uninstalled all plugins except C/C++, Java and Jacoco. Does it mean that scanner scans only .c .cpp .h files and so on? Or does it still takes all other like .json .md .txt? Should i narrow the focus manually?
  4. Can i lower down current value of LOC by deleting some less used projects?

Seriosly noone has nothing to add?

Came here to ask a similar question. I too would appreciate a more precise specification of how the overall LOC count is calculated. On Plans & Pricing | SonarSource it says:

How are Lines of Code (LOC) counted?

LOC are computed by summing up the LOC of each project analyzed. The LOC count for a project is the LOC count of the project’s largest branch.

But what kind of LOC are we talking about? The ones for the ncloc measure, or something else? I assume there’s something more, because otherwise it doesn’t add up:

$ curl -fs -u "${token}:" https://${domain}/api/support/info \
  | jq '.Statistics.ncloc'
9020660 # that's the value the license info page shows
$ curl -fs -u "${token}:" https://${domain}/api/support/info \
  | jq '.Statistics.nclocByLanguage | map(.ncloc) | add'
7358939 # that's ~1.7M off

My assumption (I would love to have it confirmed, or contradicted) is that comment lines are summed too (which would make sense imho, that’s also lines which get analyzed; as long as SQ doesn’t bill for blank lines…). I’ve made a quick script to grab the comment_lines measure of my projects, and it gives me an additional 1.5M lines (it’s still not quite the right sum, but it’s getting closer, and I was not looking through branches, which might explain the remaining difference).
If comment_lines are indeed the “missing” lines, then having the measure in /api/support/info statistics would be helpful. That, and a more precise definition in the above quoted Subscription and licensing FAQ.

1 Like

Answering to myself:

My assumption (I would love to have it confirmed, or contradicted) is that comment lines are summed too

Nope, wrong! The fact that in my case the “apparent” ncloc + the comment_lines was close to the “license” count of LOC was a coincidence.

I’ve now made an other script which crawls through branches of all my SQ projects, and the sum of the per-project maximum values of ncloc is (almost) exactly the LOC count (~9M) shown in the license page. I did not think there would be so much difference (20-25% on average apparently) between “main” (master) branches and “biggest” branches of these projects, which is why I was first looking for a different explanation.

So, my conclusions:

  • LOC” in the Plans & Pricing FAQ really means the same as the ncloc measure (which is of course convenient, and nice because we don’t pay for comments - no excuse for not writing javadoc :smile:)
  • having .Statistics.nclocByLanguage next to .Statistics.ncloc in /api/support/info is a bit misleading, because the former tells you about your “main” project branches, whereas the later tells you about your “biggest” project branches (that’s with SQ 8.7.1). It is an internal API though, I won’t complain, that was just me making wrong assumptions.
1 Like

So, to answer some of @Dominik_Panas’ questions, to the best of my (new) knowledge:

  1. How this limit is calculated. Is it summary of each projects largest branch or not?

Yes, it looks like it is an accurate sum of the ncloc measures (number of non-comment code lines) of the largest branch of each project.

  1. What are those values on the right side of each project summary?

That’s the ncloc of the main project branch, which might not be the largest one. Just like the date of “last analysis” is not the date of the last branch analysis.

  1. How lines are actually counted. I mean, those projects use C/C++. I uninstalled all plugins except C/C++, Java and Jacoco. Does it mean that scanner scans only .c .cpp .h files and so on? Or does it still takes all other like .json .md .txt? Should i narrow the focus manually?

The former (only .c .cpp .h files and so on), ncloc (when measured) is only about languages that your SQ recognizes/analyzes. Now, if you first analyze a project with 100k lines of XML and then later uninstall the XML plugin, it sounds possible that the ncloc measure of your project (branches) would not be updated until you re-analyze the project (branches), which could be a source of inconsistency between the lines you can “find” in SQ and the lines you’re billed for. That’s pure speculation on my side, I’ve not tested this scenario.

  1. Can i lower down current value of LOC by deleting some less used projects?

Yes, this definitely works. That, or re-analyzing with some files excluded (may have to be repeated on several branches, obviously). Or deleting that huge branch where some third-party dependencies have accidentally been commited and analyzed.

2 Likes

Hi guys,

I’m a little late to the party and @thomasgl-orange has already explained this thoroughly and well. I’m just want to

  1. verify his conclusions
  2. hit this lingering question

This is correct. The change is only going to “kick in” on re-analysis.

 
HTH,
Ann