Discover and share the best of the web!
Learn more about Digg by taking the tour.
Basics of the Unix Philosophy
software-quality.blogspot.com — or 17 rules to develop high quality software
RonnyDeWinter- 723 diggs
- digg it
- sm01, on 10/12/2007, -0/+1thanks
- Trizor, on 10/12/2007, -0/+3Brilliant. Programming in general would be easier if everyone followed these rules. Especially Diversity.
- npiv, on 10/12/2007, -0/+1I don't know if I agree completely. THese are procedural guidelines. And great when coding in a language like c.
As soon as you start OO programming, the analysis behind the code takes a whole new dimension. - ThankTheCheese, on 10/12/2007, -0/+3Rule of Silence: When a program has nothing surprising to say, it should say nothing.
Someone needs to tell Microsoft that one so Windows XP can stop bugging me every 3 seconds about inactive desktop icons, or my computer being at risk, or new hardware being found, or.... - tomasf, on 10/12/2007, -0/+2These aren't just guidelines for unix, but generally for all code. So you should really try to follow these rules when you're writing Windows (or whatever) software, too.
- vegasbright, on 10/12/2007, -1/+0Uhoh, theres 17 basics. Its not a top ten list...BEWARE!
Hehe - tdyer, on 10/12/2007, -3/+0^ dont you have daycare to be getting to?
- flump, on 10/12/2007, -0/+1"Rule of Clarity: Clarity is better than cleverness."
That goes along with writing decent comments to make things clear. Making something clever might improve the user's experience a lot. Comments > Clarity maybe? - CaughtThinking, on 10/12/2007, -0/+2there are better pages explaining this.
this one goes into detail is a personal favorite of mine.
http://www.faqs.org/docs/artu/ch01s06.html
this applies to *any* programming language or paradigm.
i found it to be the truest, most consistent approach to programming i have ever found, so digg for that reason :) - Gdjrptryjg, on 10/12/2007, -0/+1@flump
From "The Art of Unix Programming":
Rule of Clarity: Clarity is better than cleverness.
Because maintenance is so important and so expensive, write programs as if the most important communication they do is not to the computer that executes them but to the human beings who will read and maintain the source code in the future (including yourself).
In the Unix tradition, the implications of this advice go beyond just commenting your code. Good Unix practice also embraces choosing your algorithms and implementations for future maintainability. Buying a small increase in performance with a large increase in the complexity and obscurity of your technique is a bad trade — not merely because complex code is more likely to harbor bugs, but also because complex code will be harder to read for future maintainers.
Code that is graceful and clear, on the other hand, is less likely to break — and more likely to be instantly comprehended by the next person to have to change it. This is important, especially when that next person might be yourself some years down the road.
Never struggle to decipher subtle code three times. Once might be a one-shot fluke, but if you find yourself having to figure it out a second time — because the first was too long ago and you've forgotten details — it is time to comment the code so that the third time will be relatively painless.
-- Henry Spencer - CaptSnuffy, on 10/12/2007, -0/+1Extensibility really is just not building in limits or restrictions!
A lot of Windows versions have problems with the dos prompt not being able to handle directories with spaces in their names, but if you renamed a folder from the gui you could put in spaces. Stuff like that is just a useless holdover from dos that microsoft for one reason or another didn't fix. Or how about windows forcing you to give files extensions, and all storage devices have Letters that don't really do anything, they just prevent flexiblility in many cases. And the only reason i'm focusing on windows is because that's what i'm most familiar with, im sure the other OSes must share these problems to a degree. - lunar, on 10/12/2007, -0/+1The Art of UNIX Programming is a must read for any beginnner, novice, or veteran programmer. I bought the book off of Amazon and was mesmerized by the concepts Raymond wrote about. It has definitely refined my artistic skills when it comes to computer programming. Plus, its available online for free!
- WilliamTanksley, on 10/12/2007, -0/+2flump, comments are worth FAR less than clarity. Unclear code with comments usually means that the commenter was struggling to understand the code too -- and odds are that both the code and the comments are dead wrong.
It's important to understand that, as reassuring as comments feel, they are worth nothing compared to the code they're in. They're perfume -- they can be a good thing, or they can be used to cover up the stench of bad code. And if they're covering up stench, watch out -- the compiler doesn't read the comments.
I like the suggestions in Fowler's "Refactoring" book; he recommends treating comments as a warning sign. Don't remove them (comments aren't BAD), but just step carefully. When you're about to insert a comment explaining your code, consider whether you could instead write code that didn't need the comment.
For example:
// compute frobenheimer transform of x
x = f(x);
Becomes:
x = computeFrobenheimerTransform(x);
...as a result, human readers and the compiler see the same thing.
-Billy - estacado, on 10/12/2007, -0/+0"Rule of Clarity: Clarity is better than cleverness."
But how will people know what a genious you are. If you're not smart enough to understand the code, you're not good enough to edit it. ;)
Usually, I have twenty or so lines of comments to explain a complex code because after a while, I too forget what the code does. - flump, on 10/12/2007, -0/+1Thanks for the replies, much appreciated.
- garagefighter, on 10/12/2007, -1/+2Ok, so I was sitting on a plane heading out to Linuxworld and struck up a converstion with an nice, older lady sitting next to me. She asked me where I was going. I said "To a Unix convention." She paused for a second then replied, "Oh, I didn't know there were so many of you."
- kartbart, on 10/12/2007, -0/+0"Diversity: Distrust all claims for one true way."
Isn't that exactly what this article says? Self-contradictory. - paulypopex, on 10/12/2007, -1/+0@garagefighter ARF!
- ickyelf, on 10/12/2007, -0/+1CaptSnufy:
Unix doesn't like long filenames either. However, many *NIX guis, including OS X, use them. In the command line, yopu have to either escape them by using the backslash or putting them in quotes. - ph713, on 10/12/2007, -0/+2"Unix doesn't like long filenames either."
Actually, Unix itself doesn't really care about your filename. It can be 234 characters long with embedded non-ascii characters and spaces in the filename and all the standard unix calls will work fine.
What you're referring to is the unix commandline shell. It requires the escaping of spaces and certain other characters in nonstandard filenames because there's just no other way to go about it. A space seperates arguments on the commandline in your shell, and unless you want "fuzzy" interpretation of what you meant to do, you therefore cannot have unescaped spaces in a filename on your shell prompt commandline (or quotes for that matter, although many other nonstandard characters will work most of the time directly from the shell if you can find a way to type them). - ursabear, on 10/12/2007, -0/+1I like this list, and the book, too...
This list, plus good comments should be a mantra for all software...
Repeat after me...:
"Modularity"
"Clarity"
...
Thou shalt not reside in an ivory tower...
Thou shalt comment...
Thou shalt learn and grow and be open to new ideas...
Thou shalt ignore "Not Invented Here(tm)" impulses...
Thou shalt not have territories... - ripcrd, on 10/12/2007, -0/+0"Diversity. I think it is an old, old sailing ship."
You think Unix could use an old sailing ship? - b7j0c, on 10/12/2007, -0/+1read "the unix philosophy" by mike gancraz, which has been updated recently
an absolutely fantastic book that you can read in a few sittings. you will definitely "get it" - CaptSnuffy, on 10/12/2007, -1/+0"Ok, so I was sitting on a plane heading out to Linuxworld and struck up a converstion with an nice, older lady sitting next to me. She asked me where I was going. I said "To a Unix convention." She paused for a second then replied, "Oh, I didn't know there were so many of you.""
LMFAO! - rcmiv, on 10/12/2007, -0/+1Good link, if only for the reminder about "The Art of Unix Programming." Great reading so far. ESR, while controversial, is still an interesting writer.
-rcmiv - DigitalHobbit, on 10/12/2007, -0/+1Definitely an interesting reminder. Most of these rules make sense, although some seem to conflict with agile development principles, which I find more important. In particular the Rule of Extensibility conflicts with YAGNI (You Ain't Gonna Need It). Keeping things simple and not thinking too soon about potential extensibility (which may or may not be needed) generally makes more sense to me, although it obviously depends on what you are building.
The Digg Toolbar for Firefox lets you Digg, submit content, and keep track of Digg even when you're not on the Digg site. Download the official 
© Digg Inc. 2008 —
Content posted by