paul   code

Here are my coding standards, independent of language. Based on best practices from different groups and colleagues including karl, jm, schwenk, kimbo, hugh, craig and others.

  1. Ease of use is more important than anything else. Don't create complicated software. Have the courage to make decisions, don't offer everything as options for the user to decide. And have the courage to build software with only small amounts of functionality, the stuff that everyone uses. Don't build something just because you can, as that leads to big software (=bugs). Do usability testing, and take the duct tape rule seriously. And involve customers in your design process. Really.

  2. Write for support and maintainability. Assume a very busy and very expensive programmer will have to fix a serious bug in your code ten years from now, and she will only have ten minutes to find and fix that bug.

  3. Do not ever skimp on good tools. Buy the hardware and software and languages which will make you most efficient at producing useful, high quality, supportable code, using tools specific for the task at hand. E.g., BoundsChecker etc.

  4. Use a good web-based database to track and prioritize tasks and bugs. Don't mistake gooey project charting software for good software process. Most software fails since programmers build the wrong things (lack of consistent understanding of task definition and priorities) and do not know the customer, not because of a lack of understanding of date dependencies.

  5. Performance. Use the machine(s) and network efficiently. Writing for performance requires that you know something about the language implementation you are using. Don't blame bad performance on the language; I've found in 20 years of software that most performance problems are caused by bad application algorithms, not bad languages. (I know a programmer who can write faster Lisp code than most programmers could do in C, since this guy understands performance.) Specs should have perfomance goals (#transactions/machine/day etc). When you find problems, you must use profilers to narrow down the problem vs. guessing and spending time on something irrelevant.

  6. Humans. The above being said, also recognize that computers and disks are "free" compared to humans (support, operations, bug fix, etc) who you should assume cost $1 million per year each. cf #2.

  7. Generalize when you have more than one use of something. This means you should usually not have any repeated code blocks. However, don't waste too much time generalizing something that actually is not going to be used more than once as that can actually make your code harder to understand. cf #2.

  8. For team projects, use revision tracking and do nightly builds, torturing the programmer who checks in something that breaks the builds or self-tests. Programmers should check-in and their code often, maybe once a week on average.

  9. For team projects, have a web-archived mailing list, and send email to this list each time you check code into the system, to celebrate, give people a head's up, and motivate others to get cranking.

  10. Get QA/Doc/Support involved from day one. Instead building code and throwing it over the wall for testing after the fact can seem to be faster but produces worse results.

  11. Do great error checking throughout your code. Use error checking tools in full force, and also build auto-tests into your modules. Have a consistent error handling mechanism with unique identifiers for each error.

  12. Build internationalization into your code from day one, even if you don't localize until a bit later. Try to find at least one team member with native non-English skills so they can play with having a parallel localized version during development.

  13. Comment your code. Don't write stupid comments that explain what the line is doing (here we add two to four) but instead explain the purpose of each method, its assumptions and uses, etc. cf #2.

  14. Naming is critical, for companies, products, domain names, email addresses, module and classes, methods and variables. Use names that are not too long but which are clear. cf #2.

  15. Global variables are generally bad, too hard to understand. cf #2.

  16. Constants should be defined at the top of the method or class/module/file where they are used, not inline in code. This will make your code easier to maintain. cf #2.

  17. Formatting of your code is important. No line should be longer than 78 characters (do not assume the guy maintaining your code in ten years will be using the same tools you use now), and in general, no method should be longer than a page. (There are exceptions to this rule of course.) Use an editor (such as emacs or whatever) that automatically formats your code for you. Use consistent tab stops. cf #2.

See Also

home Updated Mon 05-Apr-2010 5:22 AM