Sunday, September 05, 2010
 
      
Development Ethics

I was in 2 minds as to whether I should add this section to my site or not as I am well aware that some people may believe that I am stuck to a particular coding style and potentially may have problems integrating with other code bases and styles.  I must point out that this is just my current set of ethics that I have employed myself in order to keep code consistent and extremely neat, if the need arrises to code in a different style then I always do what is required of me.  On the other hand, hopefully this page will give you some idea as to my level of professionalism.

Topics
Object Orientation

One of my strongest skills in software development is the employment of object orientated architectures.  Whenever I can, I will implement an object orientated approach.  This may seem “anal” to some, but I believe that an OOP approach encourages the development of reusable code that can ultimately be added to common class libraries that can then be deployed to all existing code, and future code without having to reinvent the wheel every time.  Maintainability of code is also improved greatly using this approach and replacing a troublesome class is much easier than replacing a convoluted module that is tangled up throughout most of an application.

Variable Naming

Although by most this could be seen as breaking standards, over the years I have developed my own naming standards which have proved to be extremely efficient and more suited to a wide range of languages as opposed to just being directed at C++ development.  For a start, I don't mind using relatively long variable names, if the need is there, then that is what I shall do, regardless of time taken to write variable each time.


I begin by prefixing my variables with a single letter to specify the scope,


g = global, accessible from anywhere.
m = module, accessible from a single module (primarily VB).
c = class, accessible from within the class, always declared as private as external access should be obtained through member accessors.
p = procedural, accessible from within a single procedure.


Next I specify a 3 letter acronym which identifies the type of object.  Although 3 letters may not sound like much within a large solution, I have always found it to be adequate as many classes are only declared for that particular application, as opposed to having to be maintained throughout multiple solutions.  For example,


Col = Collection
Img = Image
Str = String
Int = Integer
SLC = SomeReallyLongNamedClass


Also note that I use initial caps for each separate word being abbreviated.


Next I use a collection of words to describe the object, it’s as simple as that.  Here are some examples of a few variables being declared,


Dim cLisRegisteredUsers as new List() = Accessible within the class, of List type, a list of registered users
Dim pStrCurUserName as String = Accessible within the procedure, of String type, a string containing the current user name
Dim gFrmAppSettings as Form = Accessible globally, of Form type, a form for accessing application settings

Code Regions

Regions, in action.

This feature is primarily for .NET based languages, but I do implement a slightly different variation for other languages using the standard commenting features.  Sticking a load of code in a region is an extremely easy task, but when it’s not done it can make things extremely unreadable, so for the sake of a little extra effort I always follow the same scheme as outlined below.


In every class I use the following code regions, and typically in this order,


Private Constant Definitions
Public Constant  Definitions
Private Enum Definitions
Public Enum Definitions
Private Structure Definitions
Public Structure Definitions
Private Variable Declarations
Private Property Interface
Public Property Interface
Constructor / Destructor
Base Class Events
Base Class Overrides
Private Methods
Public Methods
Object Events
<Interface> Definition

Each interface would typically have its own region.