Shulou(Shulou.com)06/02 Report--

In 1994, Mike Gancarz, a member of the X Window system development team, wrote "The UNIX Philosophy" based on his own Unix system experience and discussions with senior programmers using Unix systems in other fields.

One: small is beautiful. Two: let the program do only one thing. Third: build a prototype as early as possible. Four: portability is more important than efficiency. Five: the data should be saved as a text file. Six: extract the full value of the software as much as possible. Seven: use shell scripts to improve efficiency and portability. Eight: avoid using user interfaces with low customizability. Nine: all programs are filters for data. In addition, there are ten principles that are not shared by everyone and are even the focus of debate (such as the dispute between the macro kernel and the micro kernel):

One: users should be allowed to customize the operating environment. Second: make the operating system core small and light. Three: use lowercase letters and be as short as possible. Four: save paper and protect the woods. Five: silence is golden. Six: think in parallel. Seven: the part plus part is greater than the whole. Eight: the Pareto rule for finding problems. Nine: programs grow with demand (Worse is better). Ten: think at a level.

Rob Parker mentions the following motto in his Notes on Programming in C. Although these rules are about programming, it is not too much to be a Unix philosophy:

Rule number one: you never know where your program is going to waste time. Program bottlenecks often occur in unexpected places, so don't optimize your code until you're sure you've found it. Rule 2: test the code. Optimize the speed of the program only if you have tested the code in detail and found that part of the code takes up most of the running time. Rule 3: a fully functional algorithm (fancy algorithm) is inefficient in dealing with small-scale problems, because the constant in the time efficiency of the algorithm is very large, and the scale of the problem is often very small. Unless you know that you often encounter complex situations, make the code ugly but simple and efficient. (even if the problem is really large, try the second rule first. Rule 4: full-featured algorithms are easier to generate Bug than simple algorithms and are more difficult to implement. Try to use simple algorithms and data structures. Rule 5: data determines everything. If the selected data structure can manage the data well, the algorithm part is often self-evident. Remember, data structures, not algorithms, are the key to programming. Rule six: there is no sixth rule.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.