Skip to main content

General

 

Developers guide to debugging

(click on the image below)


Developers Guide to Debugging

  • When dealing with objects, always check that they exist and content/elements are available
  • Format dates according to system standards
  • Enforce DRY (don't repeat yourself) principle
  • KISS (Keep it simple stupid)
  • Each method does only 1 thing
  • Enums are singular
  • Method names make sense
  • NULL checks performed
  • Used "var" instead of type in variable declaration/instantiation
  • Any IF used with ELSE-IF must have an ELSE specified, unless the default values are configured above the IF
  • Removed the old author from the method. Tracking of who made the change can be done in Git.
  • Use object initializer instead of empty constructor, when setting properties.
  • Ensure that null checks are performed and handled, where necessary.
  • Ensure that array/row/column length checks are performed and handled, where necessary.
  • Use the var keyword instead of long namespace.object.names if the type that is returned is clear from the variable initialisation.
  • Ensure the proper use of extension methods and overloads. When you have to pass in a few null values for a method, consider making another overload. Also check that the null value is handled properly to avoid null exceptions. Should this value be null to start with OR Use a POCO object
  • Are method arguments validated and rejected with an exception if they are invalid?
  • Lambda expressions – variables should make sense. Abbreviations can be used as long as it makes sense.
  • Is foreach used in preference to the for(int i...) construct?
  • Naming conventions for variables and methods. Examples:
    • Method names
    • Constant names
    • Enums
    • Public variables
    • A method name must always be in Pascal case
    • A local variable must be Camel case.
    • Public variables must be Pascal case.
    • A bool property or method must indicate that it is a bool by just looking at the name: IsActive instead of just Active.
    • The following must be Pascal case:
  • Use translation Resources instead of hard coded text, especially for enums and meta data annotations. Also ensure that the translation resources are generated correctly using the admin page. Find steps here.
  • Always prefix an interface with the letter I, for example ITransaction, IAuditable, etc.
  • When naming an interface, where possible use adjective phrases, for example IRunnable, IAuditable, IPersistable, IDisposable, IComparable, IEnumerable, however, nouns can also be used such as ITransaction, IHttpModule, etc are allowed when deemed necessary.
  • Use singular form in naming Enums, unless the enum represents bit-wise flags, where plural names should rather be used.
  • When using generic type parameters in a generic type based classes or methods, use descriptive names such as IDictionary<TKey, TValue>, and prefix all generic type parameters with the letter T.
  • Only use the letter T as a generic type parameter if it self-explanatory and usually the only generic type parameter, for example ICollection<T>, IEnumerable<T>, etc.
  • When extending from the following classes, add the base class name as a suffix:
    • System.EventArgs, e.g. System.RepeaterEventArgs
    • System.Exception, e.g. System.SQLException
    • System.Delegate
Back to top