home ‣ Good programming practices   

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.

Posted on 17 November 2002
← newer • 497 of 636 • older →