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.
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.
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.
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.
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.
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.
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.
“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.
This rule relies on RULE 3 (WRAP ALL PRIMITIVES AND STRINGS), 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:
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.