Coding Standards

For either a team or individual to develop clean, consistent and easily maintained code
an agreement to a set of coding standards should be made by all developers.
I personally try to adhere to the following standards:
  • A consistent directory structure should be used both for development and deployment.
  • Source files should have a commented header section (see sample below).
  • The order of the modules in a class should be: Header, 'using' directives,
    Types and Constants, Data, Properties, Constructors, Destructor and then Methods.
    It's easier to see these sections with a comment line of dashes between them. (see sample below)
  • Enums and constants should be in upper case with an underline between words,
    for example: public const int MAX_LENGTH
  • Most private members should be labeled protected to allow for possible inheritance in the future.
  • Public members start with uppercase letters. Protected members start with lowercase letters.
    Words in method names and identifiers start with a capital letter (initial capped).
  • Nearly all information retrieval functions should be Properties. For example, retrieving a
    calculated percentage level should reference the Property myObject.PercentageLevel, not
    call a Method myObject.GetPercentageLevel()
  • Property names are initial capped copies of protected members. For example, the Property
    'Count' works with the protected member 'count'.
  • If a Property simply returns and stores the protected member without any manipulation,
    computation or database lookup, then the member should be public.
  • All Class, Method and Identifier names should be self explanatory. I try to avoid cryptic or
    meaningless names such as ‘tr5’ or ‘str’ or ‘f32r’. If a string holds someone's first name then
    call it ‘firstName’ not ‘strFN’. srcTxt should be sourceText, PrtRep() should be PrintReport().
  • No hanging braces on the end of lines. Matching braces should line up with each other vertically.
  • Indentation (tabs) should be two characters. Tab characters should be converted to spaces.
  • Classes should be representations of 'Real World' objects or concepts. Not clumps of non-object
    code like ‘Common’, ‘Globals’, ‘Counters’ or ‘Formatters’.
  • I understand that software development is an evolutionary process. Discoveries are made during
    implementation that sometimes require re-thinking an architecture. When this happens, I re-write
    to the "new and improved" architecture. I do not try to patch or fudge a situation to work in a
    flawed architecture.
  • Above all, keep the architecture and implementation simple. Most programmers have heard of KISS
    (Keep It Simple Stupid), but I've noticed very few developers pay any attention to it.
I use the following C# class template.
//---------------------------------------------------------
//
//     FILE: apple.cs
//  CLASSES: Apple
//
//   AUTHOR: Bill Daniels
//           Copyright (c) 2011,
//           D+S Tech Labs, Inc.
//           All Rights Reserved
//
//    USAGE: ...
//
//    NOTES: ...
//
//---------------------------------------------------------
              
using System;
using System.Windows;
using System.Windows.Controls;
              
//---------------------------------------------------------
//   CLASS: Apple
//  PARENT: Fruit
//---------------------------------------------------------
              
public class Apple : Fruit
{
  //--- Types/Constants -----------------------------------
              
  (enums, etc.)
  (const, etc.)
              
  //--- Data ----------------------------------------------
              
  public    string  Color;  // public member start with upper case letter
  protected int     size;   // non-public members start with lower case letter
              
  //--- Properties ----------------------------------------
              
  public int Size  // property names should be initial capped version of protected member
  {
    get
    {
      ...
      return size;
    }
              
    set
    {
      ...
      size = value;
    }
  }
              
  //--- Constructor ---------------------------------------
              
  public Apple (...)
  {
    ...
  }
              
  //--- Destructor ----------------------------------------
              
  public ~Apple ()
  {
    ...
  }
              
  //--- Method1 -------------------------------------------
              
  public void Method1 ()
  {
    ...
  }
              
  //--- Method2 -------------------------------------------
              
  public void Method2 ()
  {
    ...
  }
}
              
I also line-up common attributes and equal signs in my code.
It's just easier to read and maintain. These two chunks are the same.
public int TotalAdjustments = 0;
protected Label prompt = new Label ();
protected ListView[] reportLists = new ListView[4];
private float customerEarnings = 0.0F;


public    int         TotalAdjustments = 0;
protected Label       prompt           = new Label ();
protected ListView[]  reportLists      = new ListView[4];
private   float       customerEarnings = 0.0F;
              

Home