18 principles in software authoring and design

18 principles in software writing and design write here, you often look at it. Author Diggins is a Canadian senior technician with 25 years of programming experience, worked for Microsoft and Autodesk, and founded two profitable internet companies.

The following 13 and 14 are also called shy principles.

1. Avoid the principle of repetition (Dry-don ' t repeat yourself)

The most basic principle of programming is to avoid duplication. There are always many structures in the program code, such as loops, functions, classes, and so on. Once you repeat a statement or concept, it is easy to form an abstract body.

2. Abstract principles (Abstraction Principle)

Related to the dry principle. Keep in mind that every important feature in your program code can only appear in one place in the source code.

3. Simple principle (Keep It easy and Stupid)

Simplicity is the goal of software design, simple code takes less time, less loopholes, and is easy to modify.

4. Avoid creating code you don't want Avoid Creating a YAGNI (you aren ' t going to need it)

Don't create a new feature unless you need it.

5. The simplest thing to do as much as possible (do the simplest thing that could possibly works)

Do as much as you can to run the simplest thing. In programming, be sure to keep the simple principle. As a programmer constantly rethinking, "how do you simplify your work?" This will help keep the path simple in the design.

6. Don't let me think (Don ' t make me think)

This is the title of a book by Steve Krug, and it's also about programming. The code you write must be easy to read and easy to understand, so that others will appreciate it and can give you some rationalization advice. On the other hand, if the program is difficult to solve, other people will always avoid the distance.

7. Opening and closing principle (open/closed Principle)

The Software entities you write (classes, modules, functions, etc.) are best open source so that others can develop. However, for your code, you have to restrict others from being modified. In other words, other people can write based on your code, but can't modify your code.

8. Maintenance (Write code for the maintainer)

A good code should enable me or others to continue to write or maintain it in the future. Code maintenance, perhaps I will be easier, but to others but more troublesome. So you write the code to make it as easy as possible for others to maintain. "If a maintainer does not continue to maintain your code, it is likely that he is tempted to kill you," the book says. ”

9. The least surprising principle (Principle of least astonishment)

The least surprising principle is typically referenced in the user interface, but the same applies to code written. The code should be as minimal as possible to surprise the reader. In other words, the code you write needs to be written only as required by the project. Other gorgeous features are not necessary to avoid self-defeating.

10. Principle of sole responsibility (single Responsibility Principle)

The functionality of a code should ensure that only a single, clear execution of tasks is performed.

11. Low coupling principle (Minimize coupling)

Any part of the code should reduce the dependency on other area codes. Try not to use shared parameters. Low coupling is often the hallmark of a perfect structural system and excellent design.

12. Maximum cohesion principle (maximize Cohesion)

Similar function codes should be placed in one section as much as possible.

13. Hide implementation Details (hide implementation Details)

Hides the implementation details principle and minimizes the impact on other components when other functional parts change.

14. The Dimitri rule is also known as the least knowledge principle (law of Demeter)

The code is connected only to parts that are directly related to it. (for example, the part inherits the class, contains the object, the parameter passes the object, etc.).

15. Avoid premature optimization (Avoid premature optimization)

Unless your code is running slower than you think, don't optimize it. If you really want to optimize, you must first figure out how to use the data to prove that it is faster.

"Premature optimization is the root of all evils"--donald Knuth

16. Code reuse is good)

Reusing code can improve the readability of code and shorten development time.

17. Separation of concerns (separation of concerns)

The functions of different domains should consist of different codes and the smallest overlapping modules.

18. Embrace changes (embrace change)

18 principles in software authoring and design