| Comments | Putting comments inside your code risks obscuring the code, instead of making things more clear. | Comment the class and the methods you expose. Keep comments out of the code itself. Only place the WHY in comments, never the WHAT. |
| Long methods | A shorter method is better readable, easier to understand en easier to debug. | Keep methods short and clear. Split into multiple smaller methods if you can’t |
| Long parameter lists | The more parameters you pass, the less readable the code is. Perhaps the object is not the correct one to perform this operation if it needs so much external information either. | Limit the number of parameters you pass, use an object to combine the parameters if you must. Check if there is an other object with more knowledge that could be better suitable to perform the operation. |
| Duplicated code | Duplicated code should be removed where possible, near duplication should be examined if the functionality can be merged | Any duplicated code means duplicated maintenance, and a change to introduce new bugs when just 1 instance is changed. Factor out duplicated code into separate methods or classes. |
| Conditional complexity | Large conditional blocks are an indication that an other approach may be more suitable, especially if they grow or change over time | |
| Combinatorial Explosion | Multiple classes or block’s of code that do _almost_ the same thing, with just tiny variations. | |
| Large classes | Large classes have the same problem as large methods, they become polluted and difficult to read. | If the class handles multiple use cases, split into multiple use case based classes. If not, see if you can split out based on certain functionality that can be delegated. |
| | |