Coding standards vs guidelines

TAB

Coding standards are increasingly something we can automate but guidelines, learned through hard experience, direct our craft. While they are usually less black and white, they are often more valuable.

Sharing guidelines is one of the best ways to help others benefit from our experience. Here are some examples from OCC’s Team Trilobites:

Don’t return system types

    • you’ll regret it when the meaning changes and you have to chase it round the system
    • use a project-specific type, even if it adds no more functionality

Avoid inheritance, but if you have to:

    • put the logic in a base class and use abstract in preference to virtual
    • why not inheritance?
      • do you want to use a thing or be a thing?
      • do you want your callers to see all the stuff you inherited? if so, you’re not that special

Create a class or two to map file and folder locations

    • don’t ever use Path.Combine in code that needs to use files – you’ll regret it one day

Be very careful about DateTime (also refer #1):

    • DateTimes retrieved from databases are DateTimeKind.Unknown
      • ->ToUniversal() ToLocalTime() are no-ops
    • raw DateTime can also make unit testing difficult – abstract it

Contain nulls

    • nulls cause a lot of problems in code
    • it makes for very nervous programming, interrupted by many ifs and null propagation (C#)

Do lots of code review

    • you learn more about writing code this way than by writing it yourself

TAB Logo