Why you should care
Having too large source files could be compared to looking for a needle in a haystack. If developers have to massively scroll down to go to the portion of code they want to fix or to add a new functionality, it costs time and energy. Although there’s no ideal number of lines of code, it is generally accepted by software engineers that a fine-grained file base improves maintenance activities efficiency and reduces software complexity.
Business Impacts
Developer time and effort may be higher when they are required to search and understand large source files. This can also impact the ability for a development team to debug in a time effective manner, since there is a larger portion of code to comb through.
CAST Recommendations
Although code refactoring may not be required in all cases, you may a) consider splitting some of your largest file artifacts or; b) inquiring if the development team can create the same functionality, but with less code.
References
How we detect
This code insight counts the total code lines that contain instructions or decorators (comments and docstring excluded) in a source file. Depending on the value and the technology being scanned (procedural COBOL programs are generally more voluminous than oriented-object Java files), Highlight counts penalty points contributing to the Software Elegance health factor if the source file exceeds a specific length limit.
About CAST and Highlight’s Code Insights
Over the last 25 years, CAST has leveraged unique knowledge on software quality measurement by analyzing thousands of applications and billions of lines of code. Based on this experience and community standards on programming best practices, Highlight implements hundreds of code insights across 15+ technologies to calculate health factors of a software.