home ‣ Good programming practices

17 Nov 2002

← newer • 449 of 588 • older →

Good programming practices.
OSA Foundation is a project to follow. They have a high-quality people on the board, as evidenced by
this post on good programming practices:

Off the top of my head, here's a quick partial list of things that I think are important:

Continuous releases and daily builds
Rather than put a bug in the bug database, first try to fix it. Don't
code first and ask QA to find bugs.
The engineer who wrote the code is mostly responsible for QA.
No code is finished until the unit test is finished.
Good design results from getting something going quickly, followed by
lots of quick iteration.
The best architectures evolve for a long time.
Code reviews are a regular part of development.
Difficult parts of code are best done by a team of two people working
closely together.
If you see a new bug while doing something else, drop everything and
jump on the chance to fix it. It just make your life easier down the road.
It is possible to eliminate all bugs from many subsystems and you should
use techniques that make it possible, like monte carlo simulations and
exhaustive checking code whenever possible.
Complexity is your enemy -- the sooner you learn the smell of too much
complexity, the better.
Simplicity is your friend. Don't fall for a really cool fancy algorithm
unless you know you need it.
Buzzword technologies often become religious. The only thing you should
be religious about is happy customers and they don't care about buzzwords.
Don't build elaborate systems unless you know you need them.
Research existing open source project to make sure the code you need
isn't already available.
Never write a slow program.
By the time your project is finished your competitor's project will be
way better than you think.
Price is only one feature of software. It's often not the most important.
From the user's perspective, simple things should be simple and complex
things should be possible.
Automate releases.
Use source level debuggers.
Use IDEs
Don't write makefiles unless you have too.
Measure then optimize.
Always spend at least 10% of your time learning new things.
Use multiple languages, programming environments, operating systems and
programming methodologies until you are comfortable with them and learn
to appreciate the benefits of different approaches.
Use the best tools, even if they are expensive.
Optimize variable names for maximum clarity, not minimum typing.
It's OK to make mistakes. The only thing that isn't OK is to not learn
from them.
Don't leave code commented out unless it's clearly explained.
Approach each piece of code you write like it's final finished code.
Don't leave loose ends to clean up later because you'll never have time
to clean them up.
Never code an algorithm that you know won't work in the final product
either because it won't scale, run fast enough, or will have a rare
failure case.
All successful products have a life longer than you can conceive. Files
and processors will grow by factors of 10,000 -- make sure your design
can accommodate change.
Don't code the first algorithm that comes to mind. Try to examine all
possible approaches and choose the best. Get someone to review your
approach before coding.
Don't put band aids on bad code, rewrite it. At first is seems hard, but
after you've done it awhile you'll find successive rewrites go much
faster than you thought.
When you work on someone else's code, don't leave it in worse shape than
it came to you. Ask the original author to review your change.
No bug is impossible to fix.
Get to be good friends with a programmer, designer, or writer who's
better than you.