17 Programming principles in the Unix programming art-the highest principle for design developers

UNix programming Art17-Point Programming philosophical principles in

--- High standards for design developers

 

Translator: July November January 13, 2011.

References: The art of Unix programming
By Eric Steven Raymond

Author's Note: This article is based on the English version of the Unix programming art book, the first chapter, the translation.
During the translation process, refer to the Chinese version (translated by Jiang Hong and others ). If you have better translation comments, please leave a message.
---------------------------------------

I. Introduction to the art of Unix programming
This book mainly introduces the design and development philosophy, ideological and cultural system, principles and experience in the Unix system field,
Eric S. Raymond, a recognized Unix programming master and one of the open source sports leaders, has been writing for many years.

 

Many experts in the field, including UNIX designers, also contributed valuable content to this book.
This book covers community culture, software development design and implementation, with wide coverage and profound content. It fully demonstrates the author's profound experience and field wisdom.

Ii. Foundation of UNIX Philosophy
Doug McILROY, inventor of the UNIX pipeline and founder of the UNIX tradition,
The UNIX philosophy is summarized as follows:
OneProgramDo only one thing and do well. The programs to be compiled must collaborate with each other,
At the same time, you must be able to process text streams because they are the most common (or basic) interface.

 

Rob Pike is the greatestC LanguageIn <notes on C Programming>,
From different perspectives, the following principles of UNIX philosophy are elaborated:
Principle 1: You cannot determine where the program will consume its running time. Bottlenecks often appear in unexpected places,
So, don't rush to find a place and change it unless you have found and confirmed the crux of the problem.

 

Principle 2: Estimate. You have noCodeBefore overall estimation, especially before finding the most time-consuming part,
Don't worry about optimization speed.

 

Principle 3: fancyAlgorithmGenerally, N hours are slow. Because the constant complexity of fancy and impractical algorithms is very high.
Unless you can determine that N must be very large, do not take the liberty to use the fancy algorithm (even if n is very large, we should give priority to principle 2 ).

 

Principle 4: Fancy algorithms are more prone to errors (bugs) and more difficult to implement (maintain) than simple and practical algorithms ). Therefore, when you do not have,
Use simple algorithms as much as possible to work with a simple data structure.

 

Principle 5: data is overwhelming. If you have selected the correct data structure and organized everything in a well-organized manner,
Therefore, correct and efficient algorithms are self-evident. The core of programming lies in the data structure rather than the algorithm. (Only representative of Rob Pike's personal opinion ).

 

Ken Thompson, the designer and practitioner of the original unix version, said in the face of Rob Pike's Principle 4 above:
If you are not sure about it, let's do it.

Iii. UNIX philosophical principles
More UNIX philosophical art is embodied by everything they do, including UNIX itself, rather than being elaborated by the philosophers.

. Overall, it can be summarized as follows:17Point principle:

1. Rule of modularity: Write simple parts connected by clean interfaces.
1. Module principle: Try to use concise interface sets and simple components.
As Brian kernighan once said, "The essence of computer programming is to minimize the complexity of programs ".
Designing a program, debugging and Error Correction often takes most of the development time, and finally gets a ready-to-use system,
It is not so much a brilliant design result as a result of a bumpy journey.

 

The only way to compile complex and huge software is to control it and reduce the overall complexity of the program. Several modules are combined into a complex software with clear interfaces.

This is the module principle, that is, the module should be modularized as much as possible, and the coupling between modules should be reduced. This is so independent that the whole body will not be moved when the changes are made.

2. Rule of clarity: clarity is better than cleverness.
2. Clear principle: Clear is better than clever.
The program is executed for the computer, but it is for people to see, such as later maintenance of the program.
An obscure program will severely block the subsequent maintenance, correction, performance improvement, algorithm optimization, and other work.

 

Therefore, when writing a program, always remember to write a clear and easy-to-understand program and add useful comments.
It is advantageous to others.

3. Rule of composition: design programs to be connected to other programs.
3. Combination Principle: Connection and combination should be considered during design.
Consider making programs communicate with each other as much as possible, so that programs can be combined and modules are independent of each other.

4. Rule of separation: separate policy from mechanic; Separate interfaces from engines.
4. separation principle: the policy and mechanism are separated, and the interface is separated from the engine.
If the policy and mechanism are mixed into one group, there will be two negative effects,
First, policies become rigid, making it difficult to adapt to changes in user needs. Second, doing so will also mean that any policy changes will most likely be shaken to the entire mechanism.

 

On the contrary, if the policy is the same as the mechanism and the two are separated, the original mechanism may not be broken when trying a new policy.
In addition, I can easily compile good test cases for the mechanism.

5. Rule of Simplicity: Design for simplicity; add complexity only where you must.
5. Concise Principle: The design should be as concise as possible, and the complexity should be lower.
Some programmers often like to tamper with complicated things to show or satisfy their own sense of superiority and excitement.
Programmers are very smart. They are proud to be proud of being capable enough to play with complicated and abstract things.

 

But at the same time, they will be deeply disgusted with the program's debugging and Error Correction Work after playing with complicated and confusing things.
This is because the cost of making a mystery is a pile of costly waste products.

Therefore, the best way is to be concise and beautiful. Everything is concise.

6. Rule of parsimony: write a big program only when it is clear by demonstration that

Nothing else will do.
6. stingy principle: Do not write large programs unless you have no other choice.
This point is similar to the 5th point. It is concise and beautiful. Do not deliberately write large and complex programs.

7. Rule of transparency: Design for visibility to make inspection and debugging easier.
7. transparency principle: the design should be transparent and visible for review and debugging.
Fully consider transparency, visibility, and conciseness.

8. Rule of Robustness: Robustness is the child of transparency and simplicity.
8. Robust principle: robust programs are transparent and concise.
The more concise and transparent the program is, the more robust the program is.

9. Rule of representation: Fold knowledge into data so program logic can be stupid and

Robust.
9. expression (method) Principle: Fold knowledge into data in order to make the logical structure simple and robust.
Modeling to make the logical structure clear.

10. Rule of Least Surprise: In interface design, always do the least surprising thing.
10. Popular principles: interface design to avoid unconventional design.
The quality of a program is determined by the user. The most simple and easy-to-use program is often the most popular program.

11. rule of silence: when a program has nothing surprising to say, It shoshould say nothing.
11. The principle of Silence: if a program is not so picky, keep silence.
The program should not have redundant parts, as concise as possible, do not have unnecessary features.

12. Rule of repair: When you must fail, fail noisily and as soon as possible.
12. remedy principle: if an exception occurs, exit immediately and provide sufficient error information.
Try to terminate the program in a way that is easy to diagnose.

13. Rule of Economy: programmer time is expensive; conserve it in preference to Machine

Time.
13. Economic Principle: I would rather spend more time on machines than a programmer's second.
Keep in mind that the programmer's time is precious and do not waste 1 minute 1 second without reason.

14. Rule of generation: Avoid hand-hacking; write programs to write programs when you can.
14. Generation Principle: Avoid manual hack, write programs as much as possible, and let programs generate programs.
The simpler the program specification, the easier it is for designers to do the right.

15. Rule of optimization: Prototype before polishing. get it working before you optimize it.
15. Optimization Principle: A model must be created before engraving, and a model should be learned before running.
Create a prototype first, and then refine your work. Before optimization, make sure that it can be used. Otherwise, all the wonderful optimizations are useless.
Or, as Kent Beck, the extreme programming master, said, "run first, then correct, and finally fast.

 

Do not blindly consider the so-called efficiency improvement of these advantages. Early optimization often becomes the root of all evil.

16. Rule of diversity: distrust all claims for "one true way ".
16. Principles of diversity: never believe in the so-called "no second law.
Even the best software is often limited by the imagination of designers.
Einstein once said that what the world lacks is not technology, but imagination.

 

No one is smart enough to arrange everything in advance.

17. Rule of extensibility: design for the future, because it will be here sooner than you

Think.
17. Expansion principle: design focuses on the future, because sometimes the future comes faster than imagined.
Never think that your design is perfect. You can stop optimization or upgrade it.

Therefore, you need to leave a scalable space for the data format and code, and later you will find that the original choice is wise.

Therefore, the design should focus on the future.
OK. For more information, see the original book. .
---------------------------------

 

Author's statement:
My July is owned by this blogArticleAnd materials are copyrighted. Please indicate the source for reprinting or referencing any articles or materials.
To pay tribute to you. Thank you. July and July January 13, 2011.