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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- Global variables are generally bad, too hard to
understand. cf #2.
- 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.
- 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
