Rating your code from A to F

Assuming that a piece of code is functional and that it complies with its requirements, that piece of code can be rated from A to F based in two parameters, the simplicity and the extensibility.

Simplicity

The simplicity is a characteristic that tells us how easy is to understand and read the code. In order to determine how simple a code is, the following can be taken into consideration.

• Good identifiers for Class names, variables, methods…
• Straight forward logic.
• Crisp and minimal abstractions.
• Low representational gap. The representational gap is how different is the domain logic of an application from its design, having a low representational gap means that the design has very few differences with the domain logic it represents.

The simplicity is classified in “Very simple”, “Simple” or “Not simple”
Very simple: Code that doesn’t require additional documentation to be understood, any developer can pick up the code and do changes without further explanation.
Simple: Code that requires some additional documentation to be understood, only developers with some background on the design and in the business domain knowledge will be able to do changes.
Not simple: Code that requires lots of additional documentation to be understood, only senior developers with a deep knowledge of the application will be able to do changes.

 

Extensibility

The extensibility is a characteristic that tells us how easy will be to add new functionality on top of the current code, don’t confuse extensibility with over engineering, which is a bad practice. In order to determine how extensible a code is, the following can be taken into consideration.

• Atomicity, use of DRY.
• Testability. Code that includes unit tests.
• Use of design patterns.
• Low coupling

The extensibility is classified in “Very extensible”, “Extensible” or “Not extensible”
Very extensible: To add new functionality on the top of the code is really easy, no refactoring would be necessary.
Extensible: To add new functionality on the top of the existing code is relatively easy, minor refactoring would be necessary.
Not extensible: To add new functionality on the top of the existing code is difficult, complex refactoring, even redesign would be necessary.

Code Rates

 

A- Excellent code.

A is the best rate for code, it can’t be more simple and it can’t be more extensible, the problem with A codes is that is almost impossible to achieve, usually there is a trade off between extensibility and readability, that’s why I always recommend to produce B codes.

 

B- Good code

B code is good code, B code will ensure that the maintenance of the application will be much easier. This code is the one I recommend to aim for.

 

C- Average code

C code is what some developers consider good enough, if we are under a tight deadline or high pressure we might have to aim for this rate of code. Maintenance of the application is harder than with B code but still is possible.

 

D- Dangerous code

With D code still is possible to maintain the application, but it takes a lot of time to perform any change and the risk to enter new bugs doing so is high, some teams don’t want to refactor D codes because they don’t want to change something that is working, that’s an error, D codes easily become E codes after a few changes and then it will become unmaintainable.

 

E- Bad code

E code is bad code, the application is unmaintainable, urgent changes are necessary, still there is time for reaction to change the code and improve it.

 

F- Start over again

Not only the application is unmaintainable, the code should be scrapped and created again from scratch