Naz-Tek Services, Inc.

Having standards are one of the most important aspects of the development process.  Whatever the standards may be, having them is important.  Enforcing corporate software development standards may be a little more challenging, check-in rules and regular code reviews can help with having processes around standards enforcements.  Here are some concrete and easily applicable guidelines:

Class

• Name
  • Pascal case, e.g., MemberCode
  • No trailing "Type" or "Class", e.g., MemberType, MemberClass, etc.
  • Trailing collection type identifier, e.g., MemberCollection : Collection<Member>, MemberList : List<Member>, etc.
• Sealed, unless otherwise necessary
• Scoped with most restrictive priority, e.g., begin with private and then broaden as necessary
• Should implement state pattern whenever state is relevent to business logic at the class level, e.g., database persistance, etc.
• Should implement as singleton whenever the class state is equally relevent throughout the library, code collection classes, etc.
• Should implement generics instead of using object whenever possible
• Collection classes should inherit from generic collection
• Must implement IDisposable if either a native or an IDisposable .net object is refrenced at the class level
• Should not exceed 200 lines of code, re-evaluate and/or refactor code coherency otherwise
• Exception handling
  • Wrap exceptions if desired
  • Allow exceptions to bubble up to the UI.  Do not handle, supress, or log them below the UI, unless absolutely necessary
• Field
  • Name
    • Preceeding underscore, e.g., _id
    • Camel cased, e.g., _memberName
    • No type information, e.g., _sMemberName
    • No scope information, e.g., _mMemberName
• Property
  • Name
    • Pascal case
  • Local variables
    • Camel case
    • Include type information, e.g., string sData, int iData, Member oMember, etc.
  • Setters should perform comparison test and ignore call if value is unchanged, otherwise set dirty state
• Method
  • Name
    • Pascal case
    • Should preceed with Get whenever applicable, e.g., GetValue()
  • Parameters
    • Name
      • Camel case
      • Preceed with a 'p', e.g., pArg
      • No type information, e.g., _pArg
    • Must be 4 or less
    • Should pass an object reference instead of multiple values from it
  • Stateless actions and functions should be static
  • Dispose localy referenced native and IDisposable .net objects, unless the object is included in the return in which case it must be disposed before going out of scope
  • Should wrap native and IDisposable .net objects in the using block
  • Should wrap persistable blocks in a transaction block only at the highest applicable level
  • Event handlers should follow the ObjectName_EventName(object, EventArgs) pattern
  • Should not exceed 20 lines of code, re-evaluate and/or refactor code coherency otherwise
• Event
  • Name
    • Should identify an action, e.g., Save, Click, etc.
    • Callback handler should identify the instance or type (for static events) name and the event name seperated by underscore, e.g., MyUser_Save, etc.
  • Use generic EventHandler(of T)
  • Should have standard signature, e.g., (object, EventAgrs), (object, MyEventAgrs), etc., note that generic EventHandler supplies standard signature

General

• Constants and variables must be localized to most common scope
• Calls should be limited to 4 levels or less deep
• Have a singular exception handling mechanism and implement wrapping and logging within it

Pre-checkin checklist:

1. Get latest from solution context menu
2. Rebuild solution
3. Verify that everything compiles