The rules, the rules of programming that we should have in mind

Demeter Principle

Another name is the principle of "knowing less and less".

Demeter is the name of the goddess of agriculture, also a goddess distributed in Greek mythology. Her name is used to mark the birth of this principle, which can be seen as a fundamental philosophy of programming born from a aspect-oriented programming (AOP) project of the same name.

The basic point of this principle is to: minimize the understanding of an object about structure, the properties of other objects other than it (including child elements).

http://en.wikipedia.org/wiki/Law_of_Demeter

Simply put, it is not possible to contact the properties and methods of other objects directly.

Wirth's law

"Software gets slower faster coal hardware gets faster" – "Hardware's speed of evolution is not equal to the rate of software degradation."

http://en.wikipedia.org/wiki/Wirth's_law

Perhaps the main idea is: programming is increasingly using rich resources so the framework must always evolve to serve that. At the same time, the hardware speed, even if it is raised, the software speed has not changed at all.

Brook's law

This is a law based on practical experience: "Getting more people into a project is slow, will only make it slower."

Or it could be said in another way: "The nine pregnant women cannot make the baby born after a month."

The basic theory of this law is

• It takes time to get used to the project
• The effort for communication will increase

http://en.wikipedia.org/wiki/Brooks%27s_law

Conway's law

"Organizations which design systems … are constrained to produce designs that are copies of the communication structure of these organizations."

"How a system design company will make the same design as its own system design."

http://en.wikipedia.org/wiki/Conway%27s_law

Recent research indicates that the company's system is the most influential factor in the issue of bug production.

http://research.microsoft.com/apps/pubs/default.aspx?id=70535

The smallest surprise principle (least astonishment)

In case, on the same interface, there are two elements that act in conflict with each other, or the behavior is not clear, then it is necessary to choose which behavior is the least surprising for the user.

http://en.wikipedia.org/wiki/Principle_of_least_astonishment

This is a user interface rule.

A simple example:

There are 2 functions on an interface:

• Press ctrl + Q to exit the program.
• Enter macros (save a keystroke that carries a certain function for ease of use later).

There will be cases where users want to use Ctrl + Q for their macros, so behave in accordance with the smallest surprise rule that is: during macro input, ctrl + Q is treated as normal key combination, not Turn off the program. This is the least surprising thing for users.

Boy Scout Principle

The principle of Boy Scout organizations is: to be clean and beautiful when going.

In the field of programming, that principle will be interpreted as "When you check in a module then it must be better than when you checkout."

YAGNI Principle

The abbreviation of "You ain't gonna need it" – That (function, part) will not be necessary.

It is a catchphrase that reminds programmers that in the Extreme Programming process: "It is not yet necessary to be allowed to do it."

DRY principle

Abbreviation for "Don't repeat yourself" – meaning "Don't repeat what is the same".

http://en.wikipedia.org/wiki/Don%27t_repeat_yourself

When this principle is applied well, even if we change a part, the unrelated parts will not be changed. Moreover, the relevant parts will be changed at the same time, greatly benefiting both the estimation and implementation stages.

KISS principle

Short for "Keep it simple, stupid" – "Just be simple, you idiot!". This is a philosophy of the US Navy.

http://en.wikipedia.org/wiki/KISS_principle

The same philosophy can be mentioned as:

Okham razor motto (Okham's razor) – "Do not make many assumptions if not necessary. What needs little hypothesis to prove will not prove with many assumptions. ”

Albert Einstein – "Doing anything should be as simple as possible, but it's too simple."

Leonardo da Vinci – "The simplest is the most sophisticated".

Antoine de Saint-Exupéry – "Perfect, it is not impossible to add, but it cannot be reduced anymore".

SOLID principles

Set of principles in object-oriented programming. The first letters merge into SOLID.

http://en.wikipedia.org/wiki/SOLID_(object-oriented_design )

SRP (Single Responsibility Principle) – "A class can only have 1 task" or in other words, "if you want to edit a class, you only have 1 and only 1 reason".

OCP (Open / closed principle) – "Open the class when you need to expand it, close the class when you need to edit it."

LSP (Liskov substitution principle) – "Subtype must always be replaced with supertype".

ISP (Interface segregation principle) – "Using multiple interfaces for different clients, it is better to use only one interface for multiple purposes" or in other words "It is not allowed to restrict access to methods that clients do not use".

DIP (Dependency inversion principle) – "The upper layer module must not depend on the underlying module. Any module must depend on the abstraction, not on the specific one. ”

ITZone via Viblo

Writer Phan Hoang Minh