UNIX Programming Art Learning notes -1__ programming

For reasons of interest, in recent years, especially in some open source architecture or projects to learn a bit of experience or methods worth learning. Think about it, always good reputation in Unix should have something worth learning. I found the English version of the UNIX programming art, it was too slow to read a day, and eventually turned to the Chinese version.

Summarize some of the principles or knowledge that you think are more useful to me:

1. Each software is only a good thing, if you need to do a new job, redesign a software instead of adding new features to the original software.

2. The output of each program will be entered as another program, even if another program is unknown. Do not have extraneous items in the output, avoid strict column format and binary, do not insist on using interactive input.

3. As early as possible to the design and compilation of the software into use, the OS is no exception. Ideally it should be in a few weeks, the botched code throws the rewrite.

4. Prioritize the use of tools rather than poor help to ease the burden of programming, 工欲善其事 its prerequisite.

5. A program to do only one thing, the program to be able to collaborate. The program has to be able to handle text streams because this is the most common interface.

6. Principle: You cannot determine where the program will consume running time, and bottlenecks often occur in unexpected places. So don't be in a hurry to find a place to change the code unless you have confirmed that it is the bottleneck.

7. Principle: Measure. Don't optimize your speed until you've measured the code, especially if you haven't found the most time-consuming part.

8. Principle: Fancy algorithms are usually very slow in n hours, while n is usually very small, and the fancy algorithm of Changshu is very complex. Unless you are sure that n is always large, do not use fancy algorithms (even if n is large, the principle mentioned in 7 is given precedence).

9. Principle: Fancy algorithms are easier to make bugs than simple algorithms, and more difficult to implement. Try to use simple algorithm to match simple data structure.

10. Principle: Data is overriding. If you have chosen the right data structure and organized everything in a well-organized way, the correct algorithm is self-evident. The core of programming is data, not algorithms.

Ken Thompson: Be poor in doubt.

12. Module principle: Use simple interface to flatten simple parts.

13. Clear principle: Clarity is better than cleverness.

14. Combination principle: The designer considers stitching combination.

15. Separation principle: Strategy and mechanism separation, interface and engine separation.

16. Concise principle: The design should be concise, the complexity can be low.

17. The principle of meanness: Unless there is no other way, do not write a large program.

18. Principle of transparency: design to be visible, reviewed and debugged.

19. The principle of robustness: robustness stems from transparency and simplicity.

20. The principle of representation: to stack knowledge into data in order to be simple and robust in logic.

21. Popular principle: interface design to avoid unconventional.

22. The principle of Silence: If a program has nothing to say, be silent.

23. Principle of Remedy: When an exception occurs, exit immediately and give sufficient information.

24. Economic principles: A better flower machine a point, do not spend a second programmer.

25. Generation principle: Avoid manual hack, try to write programs to generate programs.

26. Optimization principle: Before carving to the existing circle, before running to learn to walk.

27. The principle of diversity: never trust the so-called "begotten".

28. The principle of expansion: design looks to the future, and the future is faster than expected.

29. Some experienced developers always first define the interface and then write a simple description to describe it. Finally write the code.

30. Gluing layer is a very annoying thing, must be as thin as possible, this is extremely important.

31.UNIX programmers have always been more skeptical of object-oriented (OO) than other programmers, because of the diversity principle.

32. Global variables are modular poisons that make it easy for each module to divulge information to each other in a rash and confusing way.

33. The most effective way to pursue the transparency of code is simply not to stack too many layers of abstraction on specific operational code.

34. The program call should consider the maximum level of static depth, greater than 4 should be careful.

35. The software is maintainable if someone other than the author can successfully understand and modify the software.

36. In general, threads are not reduced but increase global complexity. Therefore, avoid using threads unless you have a last resort.

37. Adhere to structured data instead of micro language.

38. Work as little as possible, get the data to shape code, and rely on tools to separate the mechanisms from the strategy. Expert-level UNIX programmers learn to see this possibility quickly and automatically. Constructive laziness is one of the fundamental virtues of a master programmer.