Clean code

Some note for writing clean code

Michael Luo · 1 minute read

Clean Code

Clean code is code that is easy to understand and easy to change.

Software design principles

The goal of design principles help developers achieve clean code. Therefore, reduce the complexity and save time to learn the logics when software size increase.

SOLID Principles

The SOLID principles are essentially a set of rules for helping you write clean and maintainable object-oriented code.

  1. The Single-responsibility principle: "There should never be more than one reason for a class to change." In other words, every class should have only one responsibility.
  2. The Open–closed principle: "Software entities ... should be open for extension, but closed for modification."
  3. The Liskov substitution principle: "Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it."
  4. The Interface segregation principle: "Many client-specific interfaces are better than one general-purpose interface."
  5. The Dependency inversion principle: "Depend upon abstractions, not concretions."

DRY Principle

It stands for "Don't repeat yourself". It is a principle of software development aimed at reducing repetition of software patterns,replacing it with abstractions or using data normalization to avoid redundancy.

One good example of the DRY principle is the helper class in enterprise libraries, in which every piece of code is unique in the libraries and helper classes.

KISS Principle

It stands for "Keep It Simple, Stupid". KISS states that most systems work best if they are kept simple rather than made complicated; therefore, simplicity should be a key goal in design, and unnecessary complexity should be avoided.

YAGNI principle

It stands for "You Ain't Gonna Need It" . It's a principle of extreme programming (XP) that states a programmer should not add functionality until deemed necessary.Ron Jeffries, one of the co-founders of the XP, once said: "Always implement things when you actually need them, never when you just foresee that you need them."

software-engineering