This blog is targeted at beginning / novice programmers for the Visual Basic (VB) language.

Friday, February 29, 2008

Coding and Naming Conventions

This will be a quick blog. This is a topic that you should already know, and if you don't, you should stop everything and learn as much as you can about it. I'm not kidding either!

Coding Conventions:

Coding conventions is really simple. These are a set of conventions that help the programmer that is coming into a project, handing over a project, or simply returning to their own project to be able to easily read and identify what a block of code is doing and to identify properties, methods, and variables.

Here's a very simple analogy. Let's say you talked to your friend "John" and he said he was flying into JFK tonight and would like for you to pick him up. Let's even go as far to say that you don't have an idea of what he looks like, what is last name is, or what airline he flew in on. Do you think you could find him? If so, do you think it would've been a lot easier to know his last name at the minimum, or have all the information such as flight #, origination, airline, etc?

Believe it or not, programming is the same way. Think of each time you create a variable, method, or property that you were to use only 1 letter and nothing else. So, you obviously start with 'a' then go to 'b', then 'c', etc. Imagine doing an application that contains 500,000 lines of code, do you think you could easily determine what 'q' was used for? I don't think it would be simple; and the amazing part is that there are people out there doing this sort of thing.

Another common practice is to name your method with something simple like "getID", or "setName". Well, this might be ok in a small application. But what if you make an enterprise application that uses employee IDs, vendor IDs, contractor IDs…and whose name are you setting? What if the name is: Angel Flowers? Do you know if you are setting a company's name or a person's name? Can you tell later what method of 'setName' you had used? Or what 'getID' you had incorporated?

How do you stop this? Easily, use a 'best practice' and follow coding conventions. Microsoft had gone through all the trouble for you and put together a nice basic summary of suggested conventions. You can view this document at: http://msdn2.microsoft.com/en-us/library/h63fsef3(VS.80).aspx.

Naming Conventions:

This is covered briefly in the URL I provided for 'coding conventions'. But, I would like to put an emphasis on this one in particular. You'd be surprised at how this is easy to follow, requires very little memory of rules (there are only 9 rules!), and will save you hours upon hours of headache and confusion.

The emphasis I would give you are:

  • Begin each separate word in an element with a capital letter (example: ThisBasicElementUsesCapitals)
  • Begin interfaces with a capital i ("I") followed by a noun or adjective (example: IDataAdapter <or> ISession)
  • Use abbreviations when absolutely necessary and ONLY when the abbreviation is commonly known (example: "TV" instead of "Television", do NOT use "ASAU"…instead use the full name "AnotherSimpleAbbreviationUsed"…think about it, did you have a clue was ASAU was..even though I knew it, I know you probably didn't know it, nor ever would know it)

You can find additional guidelines and information at: http://msdn2.microsoft.com/en-us/library/0b283bse(VS.80).aspx.

Conclusion:

Coding conventions are great things that usually are under used and rarely emphasized (unless you work in an enterprise atmosphere). These can make your life and all those around you much easier today, tomorrow and many, many years from now.

As an everyday coder, I beg you to please look at both of these links. I'm including them once more below for easier convenience.

Additional Links:

MSDN Article – Visual Basic Coding Conventions: http://msdn2.microsoft.com/en-us/library/h63fsef3(VS.80).aspx

MSDN Article – Visual Basic Naming Conventions: http://msdn2.microsoft.com/en-us/library/0b283bse(VS.80).aspx

No comments: