Clean Code

It's important that clean code and good practices are followed, mentioned are important points:

1. DRY - Don’t Repeat Yourself
If the same logic appears repeatedly, extract/reuse it. But don’t over-abstract just to eliminate two similar lines.

2. KISS - Keep It Simple, Stupid
Prefer the simplest solution that correctly solves the problem. Clever code usually becomes maintenance pain.

3. YAGNI - You Aren’t Gonna Need It
Don’t build abstractions, configuration or features for hypothetical future requirements.

4. Separation of Concerns
Database access, business logic, UI, authentication, etc. shouldn’t become one giant blob.

5. Single Responsibility Principle
A function/class/module should ideally have one clear reason to change.

6. SOLID principles
Especially in OOP:
Single Responsibility
Open/Closed
Liskov Substitution
Interface Segregation
Dependency Inversion

7. Composition over inheritance
Instead of creating deep inheritance trees, assemble behavior from smaller components where appropriate.

8. Meaningful naming
calculateInvoiceTotal() rather than calc() or doStuff(). Good naming reduces the need for comments.

9. Small functions
Functions should generally do one understandable thing rather than being 300-line procedures with ten responsibilities.

10. Avoid magic numbers/strings
Instead of scattering 86400, "admin" or "production" everywhere, give important values names/constants.

11. Fail fast
Validate assumptions early and return/throw when something is invalid rather than letting bad state propagate.

12. Handle errors intentionally
Don't just:
try { ... } catch {}
Understand what can fail and decide whether to retry, propagate, log, recover or tell the user.

13. Defensive programming — but not paranoia
Consider nulls, empty input, malformed data, concurrency, network failures and boundary conditions.

12. Make invalid states hard/impossible to represent
Types and data structures should encode constraints where possible rather than relying entirely on runtime checks.

13. Immutability where practical
Avoid changing shared state unnecessarily. Pure functions are easier to understand and test.

14. Loose coupling, high cohesion
Related things should live together, unrelated components shouldn't know unnecessary details about each other.

15. Program to interfaces/contracts
Depend on behavior rather than concrete implementation details when that abstraction provides actual value.

16. Principle of least surprise
A function called getUser() shouldn't secretly update the database.

17. Don't optimize prematurely
Make it correct and understandable first. Measure performance before introducing complicated optimizations.

18. Comments explain WHY, not WHAT
Bad: // increment i by 1
Useful: explaining why an apparently strange workaround or business rule exists.

19. Consistent formatting/style
Linters, formatters and project conventions beat individual preferences.

20. Tests are part of the implementation
Unit tests for isolated behavior, integration tests for component interactions and end-to-end tests for critical flows.

21. Test edge cases, not just happy paths
Empty input, duplicates, huge values, failures, retries, permissions, race conditions, etc.

22. Don't test implementation details unnecessarily
Test observable behavior so refactoring doesn't require rewriting every test.

23. Refactor continuously
Working code isn't necessarily finished code. Remove duplication, improve naming and simplify once you understand the problem better.

24. Boy Scout Rule
Leave the code cleaner than you found it.

25. Read before you write
Before implementing something in an existing codebase, understand its architecture, conventions and existing utilities.

26. Don't reinvent the wheel
Check whether the codebase or standard library already solves the problem before creating another helper.

27.Keep changes focused
A bug-fix PR shouldn't unexpectedly refactor half the application.

28. Backward compatibility matters (optional)
Changing a function signature, API response or database schema can break consumers you didn't know existed.

29. Think about concurrency and state (optional)
“Works on my machine” with one request isn't proof that it works with 1,000 simultaneous requests.

30. Security isn't an afterthought
Validate untrusted input, parameterize SQL, don't expose secrets, apply least privilege and don't trust client-side checks.