Class Fattiness | Why It Should Be Measured
An INFJ personality wielding brevity in speech and writing.
What’s the size of your class? – How big is too big?
For anyone who’s writing the code, there has been this concern – what should be the ideal size of my code in a class/method/function.
It differs from each developer. As a rule of 30, Steve McConnell in his book, Code Complete says that,
If an element consists of more than 30 sub-elements, it is highly probable that there is a serious problem:
a) Methods should not have more than an average of 30 code lines (not counting line spaces and comments).
b) A class should contain an average of fewer than 30 methods, resulting in up to 900 lines of code.
c) A package shouldn’t contain more than 30 classes, thus comprising up to 27,000 code lines.
Studies show that the number of lines of code is the base upon which the quality and the complexity of the software that you are building stands on. The real value of a guideline like the Rule of 30 is when you’re reviewing code and identifying risks and costs.
Too many lines of code will be difficult to compile and test. However, there are no ideal metrics that measure the fattiness of the class. It isn’t just based on “opinion” it is based on the result of decades of practice. Code reviews help identify and rectify issues in the codebase.
Informal reviews can find 20%-30% code defects. Studies at IBM, HP, Microsoft and other places show that it is several times cheaper to find bugs in code reviews than through testing. And evidence keeps coming in to support that code reviews work.
Horus, an engineering management platform helps review the lines of code being written and what it means to the developers writing it, risks and costs associated with it to the mid and top-level management, regardless of the domain, level of maturity of the organization, or lifecycle phase during which they were applied.
Learn more about Horus in the previous article.
Read also Cyclomatic Complexity
Related Posts
