Skip to main content

Shaw's Coding Standards Rant

· 2 min read

In both my professional life, and through using open source projects I've come across what I think are some really simple code quality practices that anyone can follow. I wrote these down one day in a moment of frustration after previously fixing a build at work so that it had no "warnings" in the build, only to discover about 3 months later that other team members didn't see the 130+ yellow warnings on their visual studio errors pane. (The cool thing with visual studio is that of course you can untick the box and never see warnings... it's bliss, you never need to see the mess! It's the IDE equivalent of dust under the mat)

Some "standards"

  1. don't have warnings in your build output, if you're not using a variable remove it
  2. don't check in code with massive blocks of commented out code
  3. don't rely upon exception handling for code flow.
  4. always check if a file or directory exists prior to trying to open it. create it or return an appropriate error, don't throw an unhandled exception, or rely on a try/catch block to handle this
  5. try to use System.IO.Path.Combine for creating file paths, don't concatenate strings with slashes in them
  6. use System.Environment or other namespaces to obtain windows system path, program files path, etc to ensure x86/x64 portability and allow for the fact that windows may be installed somewhere other than c:\windows
  7. use System.Globalisation for formatting of numbers where possible
  8. don't use hard-coded currency symbols if possible (easily solved by the use of the above point)