3

So a bit of fun, but also possibly useful.

Many of you would be aware of the Zen of Python

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

Lets think up a Zen of Software Rec. For both answers and questions.

We can draw upon some great meta posts.

Getting down ideas like: - What a answer should look like (Syle wise) - One answer per post, execpt when you shouldn't - Special cases are what we are here for - First person expeirence is a must

So lets capture our guidelines into a beautiful zen like form.

I'll make my own entry into this but here is one to get started:

-Dot Points are one honking great idea -- let's do more of those

I don't think out Zen needs to be as long.

| |
2
  • Person Experience is the value we add over Google.
  • Explicit Requirements are better than implicit.
  • Specific is better than Broad.
  • Broad is better than Speculative.
  • Pricing should be listed
  • as should OS/Platform
  • Readability counts.
  • Special cases problems are what we are here for.
  • Although practicality beats perfect match of requirements.
  • Poor questions should never pass silently.
  • But be nice and help them get fixed
  • In the face of ambiguity, Comment, then Edit if you can resolve it.
  • Question as if you expect there to be one, and Only one answer to your question.
  • But, Answer with the knowledge of the wider context of the many solutions.
  • Answering now is better than no answer being given
  • But not answering at all is better than rushing your answer
  • If the operation of the software for this task is hard to explain, it's a bad solution.
  • If the operation is easy to explain, it may be a good idea.
  • Dotpoints are one honking great idea -let's do more of those!

I don't feel I've captured everything I should in this. I think I got carried away imitating the Zen of Python. Feel Free to copy and paste and edit for your own answers

| |

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .