[clug] July Programming SIG: the fourteen principles for new
endgame.dos at gmail.com
Tue Jul 15 12:42:24 GMT 2008
Paul Wayper wrote:
> 1) Don't reinvent the wheel if you can avoid it. Try to use or contribute
> to another project rather than writing from scratch.
Related: Typing the same code twice is a warning, typing the same code
thrice is a pretty good sign that there's something to abstract here.
> 4) Be as clear as possible as much as possible. Use the simplest
> mechanism you can find to do the job, without being too obscure.
> Remember that the more complex your code is now, the harder it will be
> to debug later, and make it easy to read. The extra time it takes to
> write 'username' rather than 'x' is much smaller than the time you will
> take to figure out what 'x' contains a hundred lines down. Copy and
> paste or autocompletion is your friend.
I'd be careful saying "copy & paste is your friend" to a new coder. It's
possible they could get the wrong idea.
> 5) Document your intentions in the code. Document the situations that
> you've worked around in the past - to avoid repeating past mistakes
> and to explain particular lumps of hair. Use Python's heredocs or
> your language of choice's equivalent to document the code for external
You mean docstrings, I think. Aren't heredocs things of the form:
> 14) Beware of the old badness reinvented as the new hotness. Shun
> sceptics who tell you that it can't be done, especially if their
> proof is dated more than two years ago. Spot cycles in technology
> and work with them rather than against them. Beware of listening to
> marketing and management rather than experts in forming your plans.
> Do not try to be all things to all people.
That sounds applicable to more than just programming.
I don't know if you're looking for more, but my favourite is something like:
Programming is applied laziness. If it's boring and/or repetitive,
chances are you can make the computer do it for you. If you can't, maybe
you need a better tool. Faced with spending an hour doing foo or
spending a couple of hours learning how to automate foo, choose the
latter. The time spent now will be more than saved when you run into
foo-like problems later.
More information about the linux