There are several reasons why it is important to monitor the number of lines of code (LOC) in a software development project.

Larger codebases are generally considered more difficult to maintain. They often require more complex architectural designs and larger teams, and they can be harder for individual developers to fully comprehend. As a result, working in such projects becomes more challenging and error-prone.

Additionally, some proprietary tools used in the CI pipeline — such as SonarQube — may impose licence limitations based on the number of lines of code, making it important to keep track of this metric. Usually, a SonarQube licence has a limitation of two million lines of code per instance.

It is considered best practice to monitor the total size of a codebase using the Size (LOC) metric. This should preferably be set to count only non-commented lines of code, as this focuses exclusively on executable code and excludes both empty lines and descriptive comments.

The Software Improvement Group (SIG) conducts annual research on software maintainability, including calibration of size thresholds per programming language. It is recommended to refer to their findings and use them as guidance when setting threshold values for the Size (LOC) metric.

For more information, see Chapter 3.1 “Volume” in the following document:
Trusted Product Maintainability – Guidance for Producers (SIG & TÜViT)

!

To help viewers understand the purpose and methodology behind monitoring the total codebase volume, it is recommended to add a clear and informative comment to the metric. This comment will be visible in the report when the metric is collapsed.

!

Below is a list of suggested configuration per programming language.

Programming language	Preconfigured Comment	Suggested metric target	Suggested metric near target
Java	<div> <p><a href="https://softwareimprovementgroup.com/wp-content/uploads/SIG-TUViT-Evaluation-Criteria-Trusted-Product-Maintainability-Guidance-for-producers.pdf#:~:text=3.1%20VOLUME" target="_blank"> SIG states</a> that Java code is maintainable below 342 K NCLoC.  So thresholds are 257 K = 75% (yellow) and 339 K = 99% (red)</p> </div>	342*0.75=256500	342*0.99=338580
Python	<div> <p><a href="https://softwareimprovementgroup.com/wp-content/uploads/SIG-TUViT-Evaluation-Criteria-Trusted-Product-Maintainability-Guidance-for-producers.pdf#:~:text=3.1%20VOLUME" target="_blank"> SIG states</a> that Python code is maintainable below 289 K NCLoC.  So thresholds are 217 K = 75% (yellow) and 286 K = 99% (red)</p> </div>	289*0.75=216750	289*0.99=286110
JavaScript	<div> <p><a href="https://softwareimprovementgroup.com/wp-content/uploads/SIG-TUViT-Evaluation-Criteria-Trusted-Product-Maintainability-Guidance-for-producers.pdf#:~:text=3.1%20VOLUME" target="_blank"> SIG states</a> that JavaScript code is maintainable below 369 K NCLoC.  So thresholds are 276 K = 75% (yellow) and 365 K = 99% (red)</p> </div>	369*0.75=276750	369*0.99=365310
TypeScript	<div> <p><a href="https://softwareimprovementgroup.com/wp-content/uploads/SIG-TUViT-Evaluation-Criteria-Trusted-Product-Maintainability-Guidance-for-producers.pdf#:~:text=3.1%20VOLUME" target="_blank"> SIG states</a> that TypeScript code is maintainable below 327 K NCLoC.  So thresholds are 245 K = 75% (yellow) and 323 K = 99% (red)</p> </div>	327*0.75=245250	327*0.99=323730