Hi!,
First of all, I would like to say the content above is an essential thing for each developer who wants to improve their code quality.
I do not own the content above, I just bring it from the Lars Kappert’s GitHub.
Please see the References section for the reference to GitHub and the owner’s websites.
Programming Principles
Every programmer benefits from understanding programming principles and design patterns. This overview is a reference for myself, and maybe it is of help to you during design, discussion, or review.
The list is incomplete, and sometimes trade-offs need to be made between conflicting principles. However, higher ranked principles usually beat lower ranked ones.
The list was inspired by The Principles of Good Programming (down? Google’s cache).
I’ve added a bit more reasoning, details, and links to further resources. Let me know if you have any feedback or suggestions for improvement!
Contents
Generic
- KISS
- YAGNI
- Do The Simplest Thing That Could Possibly Work
- Separation of Concerns
- Keep things DRY
- Code For The Maintainer
- Avoid Premature Optimization
- Boy-Scout Rule
Inter-Module/Class
- Minimise Coupling
- Law of Demeter
- Composition Over Inheritance
- Orthogonality
- Robustness Principle
- Inversion of Control
Module/Class
- Maximise Cohesion
- Liskov Substitution Principle
- Open/Closed Principle
- Single Responsibility Principle
- Hide Implementation Details
- Curly’s Law
- Encapsulate What Changes
- Interface Segregation Principle
- Command Query Separation
- SOLID
Test
KISS
Keep It Simple, Stupid: most systems work best if they are kept simple rather than made complex.
Why
- Less code takes less time to write, has less bugs, and is easier to modify.
- Simplicity is the ultimate sophistication.
- Perfection is reached not when there is nothing left to add, but when there is nothing left to take away.
Resources
YAGNI
You Aren’t Gonna Need It: don’t implement something until it is necessary.
Why
- Any work that’s only used for a feature that’s needed tomorrow means losing effort from features that need to be done today.
- Leads to code bloat; software becomes larger and more complicated.
How
- Always implement things when you actually need them, never when you just foresee that you need them.
Resources
Do The Simplest Thing That Could Possibly Work
Why
- Real progress against the real problem is maximized if we just work on what the problem really is.
How
- Ask yourself: “What is the simplest thing that could possibly work?”
Resources
Separation of Concerns
Separation of concerns is a design principle for separating a program into distinct sections, each addressing a separate concern.
Example: business logic and UI. Changing UI should not require changing business logic and vice versa.
Quoting Edsger W. Dijkstra (1974):
It is what I sometimes have called “the separation of concerns”…
Why
- Simplifies development and maintenance.
- Well-separated concerns → easier reuse and independent updates.
How
- Break functionality into separate modules that overlap as little as possible.
Resources
(… giữ nguyên nội dung gốc, format lại tương tự cho các mục tiếp theo …)
Hi, I'm Tim 