Hence the Remark Command which allows us to write notes in our code telling us what is happening. Unfortunately most of us believe, “I know what it is doing and I am the only one who will ever see this.” And invariably we, ME MORE THAN MOST, end up skipping the remarks which help us debug and follow the code flow. So, how do we fix this? By including in our variables the information most needed, like what is it for and what type of data does it contain.
There is a paper written by one of Microsoft’s main programmers, Charles Simonyi, which tells how to do this in 10 pages. Unfortunately, most people who read his paper mis-interpret it and invariably corrupt his original theory.
If you wish to read it you can find it here. http://msdn.microsof.../hunganotat.asp
Basically, after the programmers at MS completely and thoroughly botched the original intent of Hungarian Notation method, and it was taught in many books this way, MS officially declared Hungarian Notation to be a bad thing. When .NET came out they actually typed “Do Not Use Hungarian Notation” on a lot of the documentation.
So that brings us back to naming variables with an arbitrary name and making code difficult to follow. Now C. Simonyi had a great idea and if every programmer followed his rules the all code would essentially read the same way. A side effect of this is that we go back to having to not only use cryptic anagrams but these anagrams have to be attached to our variable name, i.e., rwvariablename means rowvariablename, and clvariablename means columnvariablename. This quickly becomes just as cryptic as the original problem it tried to correct. No one wants to lookup the required prefix for every type or object.
The best suggestion is to use a 2 or 3 character prefix on variables in our code telling us what it is, i.e. lngUserID, tells us this is a Long Value and it is obviously used to identify a User of the program. We also need to identify objects the same way, i.e., picFace, tells us we are looking at a picturebox containing the image of a face. If we are consistent with whatever prefixes we use, throughout our code, it becomes a simple thing to follow the code.
If we also use Detailed Variable names like strFirstName, strEncodedPassword, strDecodedPassword, lngUserID, lngCompanyID, lstEmployees, The code becomes self commenting and all Programmer Named Objects and Variables stand out from conventional commands, Procedures and Function calls. When creating our own Classes, Functions and Procedures we should use clClassName, fnFunctionName and prProcedure Name to further differentiate between our created code and built in code.
It really doesn’t matter what two or three characters you use as prefixes as long as they tell you what you need to know. Anyone who comes along to debug your code will quickly pick up on your convention and get through it. Yes, it would be great if everyone always used the exact same prefixes to indicate the exact same things, but this is unlikely and unreasonable to expect. So, choose your own convention and methods, but remember, three years from now, if you look at your code, you want to be able to know each variable is doing and why, without having to investigate every variable name and object back to it’s creation. Here are some obvious prefixes for some objects in the tool panel of VB 2005.
This post has been edited by KeyWiz: 20 November 2006 - 06:39 PM