en.md

Clean code that is easily understood by all team members. Clean code can be read and developed by a developer other than its author. Code readability, maintainability, modifiability, and extensibility are only possible when you properly understand how the code works.

---

General rules

1. Follow standard rules such as naming classes and functions, the amount of indentation, etc. (Standard Conventions)
2. Reduce the complexity in the code as much as possible. Simplicity is always better. (Law KISS)
3. Deliver source code cleaner than when you receive it. (Law Boy Scout)
4. Always look for finding problems and bugs in the code. To fix them, identify main and root causes. (Act RCA)

Design rules

1. Variables, constants and all configurable data must be at the highest level of abstraction. (Configurable Data At High Levels)
2. Instead of breaking the open-closed rule, use the polymorphism property. (Replace Conditional With Polymorphism)
3. (Separate multi-threading code)
4. Avoid giving your application developers too much freedom of action. (Prevent Over-Configurability)
5. Instead of creating objects (using new), use dependency injection. (Dependency Injection)
6. Functions and classes should not have access to other details in the code except what they do. (Law LoD)

Rules of functions

1. Your functions should be small. (Small)
2. Each function should do one thing only. (Do one thing)
3. The name you choose for each function should fully describe what it does. (Use descriptive names)
4. The best function is the Niladic function (Niladic). Your function should take the fewest arguments possible. (Prefer fewer arguments)
5. Your function should not change anything that is outside its scope. (Have no side effects)

Comments rules

1. Always try to explain yourself in code. If it's not possible, take your time to write a good comment.
2. Don't be redundant (e.g.: i++; // increment i).
3. Don't add obvious noise.
4. Don't use closing brace comments (e.g.: } // end of function).
5. Don't comment out code. Just remove.
6. Use as explanation of intent.
7. Use as clarification of code.
8. Use as warning of consequences.

Tests

1. Each test (it is better) to have just one assertion. (One Assertion Per Test)
2. Follow the F.I.R.S.T rules.
   1. Your tests must run quickly, even if there are 1000 of them. (Fast)
   2. Your tests should be isolated and independent and nothing, including the operating system, environment variables, other programmer's codes, should interfere with their work. (Isolated/Independent)
   3. Your tests should be conclusive and repeatable, their variables should not change in different environments. (Repeatable)
   4. (Self-validating)
3. Your tests should be easy to read and understand. (Readability)

Error handling

1. Don't mix error handling and code.
2. Use Exceptions instead of returning error codes.
3. Don't return null, don't pass null either.
4. Throw exceptions with context.