9 Rules for a Better Code

written by MLADEN PAIĆ

Object Calisthenics are basically programming exercises, formalized as a set of 9 rules.
By trying to follow these rules as much as possible, you will naturally change how you write code. Of course, it doesn’t mean you have to strictly follow all these rules, all the time.

Here are the 9 rules for writing a better code:

1. Only One Level Of Indentation Per Method
2. Don’t Use The ELSE Keyword
3. Wrap All Primitives And Strings
4. First Class Collections
5. One Dot Per Line
6. Don’t Abbreviate
7. Keep All Entities Small
8. No Classes With More Than Two Instance Variables
9. No Getters/Setters/Properties

#1: Only One Level of Indentation per Method

Having more than one indentation level is often considered bad for readability and maintainability, it's not easy to understand the code without executing step by step in your head, especially if there is a loop in another loop, or if there are multiple conditions nested.

By following this rule, code will be split into separate methods. The number of lines will not be reduced, but the readability will be improved significantly.

#2: Don't Use The ELSE Keyword

If else cases can get hard to read, and they don't really bring any value to the code.
An easy way to remove the else keyword is to implement an early return solution.

#3: Wrap All Primitives And Strings

To avoid Primitive Obsession, all the primitives should be encapsulated within objects. If the variable of your primitive type has a behavior, you MUST encapsulate it.
Objects like Money, or Hour for instance.

#4: First-Class Collections

The collection class should not contain any other member variables. If you have a collection of elements and you want to manipulate them, you should create a dedicated class.
Each collection gets wrapped in its own class, and all the behaviors for filtering applying rules are encapsulated inside of it.

#5: One Dot Per Line

Method calls should not be chained (this does not apply to Fluent Interfaces and Method Chaining Pattern, any other class should respect this rule). It's directly related to respecting the Law of Demeter. Objects should talk only to closest friends.

#6: Don't Abbreviate

If you keep writing the same name over and over again, that will probably lead to code duplication.
If the class/method name is too long, it probably means that it has more than one responsibility, violating SRP. Naming is a big thing and can improve your code a lot. Abbreviations can lead to confusion because not everybody will understand what abbreviation means, so the trade-off is not worth it.

#7: Keep All Entities Small

“No class over 50 lines and no package over 10 files.”
The idea behind this rule is that long files are harder to read, harder to understand, and harder to maintain.
This is obviously very hard to apply (not even applicable to some languages like PHP, but it can be adapted), but IMO classes/methods should be somewhat short and this rule should be applied to some concern, but respecting these exact numbers (50 lines, 10 lines) is not crucial. As long as your classes are not more than 100-200 lines (especially in languages like PHP), it's not that big of a deal.

#8: No Classes With More Than Two Instance Variables

This rule relies on RULE 3 (Wrap All Primitive and Strings), and its benefits are high cohesion, and better encapsulation.
The main idea is to distinguish two kinds of classes, those that maintain the state of a single instance variable, and those that coordinate two separate variables. Two is an arbitrary choice that forces you to decouple your classes a lot.
IMO this doesn't have to be exactly two instance variables but should be kept to a low number and it can be applied like in the following example:

#9: No Getters/Setters/Properties

As long as you don't use the result of the accessor to make the decision outside of the object it should be okay. Any decisions made upon the state of the object should be done inside of the object itself. That's why getters and setters are bad, they violate Open/Closed Principle directly.

In the end, some rules are very easy to follow and they will improve your coding a lot, other ones are not the easiest ones to pull off. It's up to you to decide when and which one you want to implement and practice them in your spare time.

One Rule For Better IT Solutions- Quantox!

Quantox programmers and developers are a team and as such they've adopted coding practices which makes the code understandable for every team member. By having a clean code we can all participate in creating a better, stronger and safer applications for our clients. Here, a good organisation is the key, and we start at how we write your code. Let's Talk!