UNIX-Philosophy

Discussion of programming on Linux, including shell scripting, perl, python, c/c++, mono, java. Whatever tickles your fancy.
Post Reply
aquiline
Company Havaldaar Major
Posts: 178
Joined: Sat Nov 20, 2004 5:56 pm
Location: Attock-#-Junction

UNIX-Philosophy

Post by aquiline »

Herez just for General programming tips, just got when reading an excellent book =>
Addison.Wesley.Eric.Steven.Raymond.The.Art.of.UNIX.programming

http://www.archive.org/details/Addison. ... rogramming
..Few lines.......Happy Reading & let's share your programming experience in UNIX-LINUX, regardless of any particular languages /etc ......... ! :idea: :arrow:
/* Basics of the Unix Philosophy
********************************** */
//
Rule of Modularity: Write simple parts connected by clean interfaces.
**********************************************************************
Rule of Clarity: Clarity is better than cleverness
**********************************************************************
Rule of Composition: Design programs to be connected with other programs.
************************************************************************************
Rule of Separation: Separate policy from mechanism; separate interfaces from engines
*************************************************************************************
Rule of Simplicity: Design for simplicity; add complexity only where you must
**************************************************************************************
Rule of Parsimony: Write a big program only when it is clear by demonstration that nothing else will do
********************************************************************************************************
Rule of Transparency: Design for visibility to make inspection and debugging easier
***********************************************************************************
Rule of Robustness: Robustness is the child of transparency and simplicity.
***************************************************************************
Rule of Representation: Fold knowledge into data, so program logic can be stupid and robust
*******************************************************************************************
Rule of Least Surprise: In interface design, always do the least surprising thing
*********************************************************************************
Rule of Silence: When a program has nothing surprising to say, it should say nothing
************************************************************************************
Rule of Repair: Repair what you can — but when you must fail, fail noisily and as soon as possible
**************************************************************************************************
Rule of Economy: Programmer time is expensive; conserve it in preference to machine time
*****************************************************************************************
Rule of Generation: Avoid hand-hacking; write programs to write programs when you can
*************************************************************************************
Rule of Optimization: Prototype before polishing. Get it working before you optimize it
***************************************************************************************
Rule of Diversity: Distrust all claims for one true way
*******************************************************
Rule of Extensibility: Design for the future, because it will be here sooner than you think
*******************************************************************************************
//
}
Sh@Ring is Le@Rning
Post Reply