Sundarrajk's Weblog

Archive for the ‘Cs of Code Quality’ Category

Coupling: This indicates that the different packages are interlinked and the concerns are not separated.
A single change may require changes in multiple disparate packages/modules.
This makes the system fragile to changes
Copied Code: Code that is copied all over the place is bad code.
It causes unexpected errors. The developer will typically fix in one place and forget to fix it at other places.
Developer gets bored fixing it in all the locations.
Comments (What?): If we find comments which says what a piece of code is doing or explains the code it is bad comment and bad code.
If the developer feels that she needs to explain what the code is doing then it is not clear code and that is not good.
Colossal: If the code blocks are big then then it is bad code even if it addresses the functionality
Large blocks of code (classes, methods) are bad news as they make reading difficult
Complexity: If a code is too complex (cyclomatic complexity) it is bad code
High degree of Cyclomatic complexity means that testing the code become as much difficult and this in turn puts a doubt on the tests conducted.

Correctness: The code should be correct and do what it is expected to do.
Cohesion: represents unity of purpose.
A good cohesion indicates that the classes that are related and are dependent on each other are co-located.
This will ensure that when changes need to be made the change will be within a limited area of code
This will limit the mistakes that the developers will make when making changes
Clarity: A good clarity indicates that code can be read and understood.
New developers will be able to read and understand the code
It will reduce the errors during change as the code is clear and understandable
Comments (Why? How it can be used?): The comments say why a piece of code exists and how it can be used are good comments.
Categorical: The code should be Categorical about what it does and it should do that one single thing “Categorically”. It should not do more than that one thing.
If the code does only one thing the reader of the code is not misled
Concise: The code should be as small as reasonable and should provide a clear picture of what it is doing.
This makes reading and maintenance easy, reducing possibility of errors.