Solid principles

You MUST abide by SOLID principles:

• Single Responsibility Principle (SRP): A class or module should have only one reason to change, meaning it should have a single, focused purpose. 
• Open/Closed Principle (OCP): Software entities (classes, modules, functions, etc.) should be open for extension but closed for modification.
• Liskov Substitution Principle (LSP): Subtypes should be substitutable for their base types without altering the correctness of the program. 
• Interface Segregation Principle (ISP): Clients should not be forced to depend on interfaces they don't use. 
• Dependency Inversion Principle (DIP): High-level modules should not depend on low-level modules. Both should depend on abstractions. 


Keep it dry

You should keep it D.R.Y — do not repeat your code

Keep it simple

Keep it simple, stupid — favour simplicity

Separate concerns

Divide the code into distinct modules or components, each responsible for a specific task or area of functionality. 

Abstraction


Hide complex implementation details and expose only the necessary interface, making code more manageable and reusable

Clean Code

Prioritize code readability, maintainability, and clarity. Follow coding style guidelines and use meaningful names

Documentation


Provide clear and concise comments to explain complex logic and design decisions. Specifically use doctrings to make code readable by computers and people

Testing

Write unit tests and integration tests to verify code correctness and prevent regressions

Robustness

• Design code to handle unexpected inputs or errors gracefully, preventing crashes or unexpected behavior
• Avoid Premature Optimization:
• Focus on writing clear and correct code first, then optimize only where necessary

Law of Demeter


Each unit should only interact with its immediate neighbors, minimizing dependencies between unrelated parts of the code.