Some notes regarding Unix Philosophy (actually in my opinion they apply to general good programming practices) based on "The Art of Unix Programming by Eric Steven Raymond" (http://www.catb.org/esr/writings/taoup/html/graphics/taoup.pdf)

Unix Philosophy - rules

Basics of Unix philosophy:

- Use simple algorithms as well as simple data structures
- Data structures, not algorithms are central to programming - organise it well
- Fancy algorithms are buggier than simple ones

Rules:

Modularity - build out simple parts connected by well defined interfaces. Be able to update/upgrade the part without breaking the whole.

Clarity - clarity is better than cleverness. Maintenance is important and expensive, write programs as if they do not only communicate to the computer but to the human being that will later read & maintain this code (especially if that’s you). Buying a small increase in performance with a large increase in the complexity and obscurity of your technique is a bad trade.

Simplicity - designer simplicity; add complexity only where you must. Put a high value on simple solutions, that looks for ways to break program systems up into small cooperating pieces. Do not compete to build the most intricate and beautiful complexities - often the ability to design outstrips the ability to later implement and debug, and the result might be an expensive failure

Transparency - design for visibility to make inspection and debugging easier. A program should be able to both demonstrate its own correctness (display internal state) and communicate to future developers the original developer’s mental model of the problem it solves. For a program to demonstrate its own correctness, it needs to be using input and output formats sufficiently simple so that the proper relationship between valid input and correct output is easy to check.

Robustness - (the ability to withstand or overcome adverse conditions or rigorous testing). Software is said to be robust when it performs well under unexpected conditions which stress the designer’s assumptions, as well as under normal conditions. One very important tactic for being robust under odd inputs is to avoid having special cases in your code. Bugs often lurk in the code for handling special cases, and in the interactions among parts of the code intended to handle different special cases.

Representation - Data is more tractable than program logic. If you see a choice between complexity in data structures and complexity in code, choose the former. More: in evolving a design, you should actively seek ways to shift complexity from code to data.

Rule of Least Surprise - The easiest programs to use are those that demand the least new learning from the user (are those that most effectively connect to the user’s pre-existing knowledge). Pay attention to your expected audience. They may be end users, they may be other programmers, or they may be system administrators. 

Rule of Silence - Well-designed programs treat the user’s attention and concentration as a precious and limited resource, only to be claimed when necessary.

Rule of Repair - Write your software to cope with incorrect inputs and its own execution errors as gracefully as possible. But when it cannot, make it fail in a way that makes diagnosis of the problem as easy as possible.

Rule of Optimization - Prototype before polishing. Get it working before you optimize it. “Premature optimization is the root of all evil”; “Make it run, then make it right, then make it fast”. Don’t rush to optimize before the bottlenecks are known

All the above in one lesson : K.I.S.S. - keep it simple, stupid.