Friday 2 July 2010

What’s in the name?

Let’s take a step back. Alright, several steps back. When you started reading this, did you get excited by the fact that you will learn something new? It will be fun? No, you thought its just another blog talking about some other weird misnomer (go get a life, watch 3 Idiots!).

If you like the practice of software engineering – you are most welcome. If you are not, then you are not wasting your time, read on, its fun. I am not as funny as a porcupine wearing a Li.Lo. (Lindsay Lohan – they say she likes girls! No big deal, even I do) red wrap-around, but you can try. Ever heard of adventure?

I thought of writing this when I was stuck in a traffic jam with all vehicles getting in way of the other – like a deadlock you know – you techie guy. But, I like saying all this (read shouting) to all those guys who are “accidently in love” (OST Shrek) with software engineering. I will call them coders from now on. These coders code for fun. Because, they make fun of coding. This is the first in series of my misadventures with coders. They have transformed me into a very calm and composed person. I am thankful to them.

I am also a coder. I like to be like this for many more years to come because I am in love with coding. Its a different matter altogether that my definition of coding captures architecting, then designing, then developing, then unit testing, and finally delivering to business with agile-ity.

We will talk about other aspects later, but for now I am concentrating on the greatest myth of all – naming the variables.

What the F. is in the name? It doesn’t matter, does it? My dear numbnuts, it does. People who care about it have written books on it. Go fetch.

Alright, tell me what could be wrong a variable names like: “strString”, or “intInt”, or for the imaginative few “iInt”, or for the pseudo-coders “strName”? Did I forget to mention i, x, y, k etc. What about F? What’s wrong in specifying the data type along with (data type?), something! Concentrate on the functional aspect of the variable not on the data type - see what it does, don’t stress on what it is. Its meaningless isn’t it? What about trying names like “firstName”, “lastName” or “totalFiles” for a change?

People try and be imaginative and use names like “m_strName”, “p_intAge”, or “g_oSessionObject” – they are just trying to attach scope of the variable with their names. No big deal. You ain’t doin’ structured programming are you?

Some of them use names like “Form_Collection.cs” in a windows application to name a Windows Form, and “Form_Collection.aspx” in a Web application. You will find all files in their solution explorer with that redundant “Form_”. Why is that? Will it become an “edmx” if you do not prefix “Form_”? Redundant, agonizing.

Some choose to use names like “TCImpersonator” or “TCComputerManagement” for their classes (kudos to them that they created one). “TC” was the name of the application. Namespaces anyone?

So, you see the different trends and patterns in naming. Mind you that I have worked in about 5 to 6 different companies, most of them very huge enterprises, and the story is same everywhere. Nobody takes this aspect of programming seriously. One of my colleagues declared that some “jobless person is given a task to create some guidelines” – they don’t even give a damn to it. But, let me tell you its very important. Its as important as a brick is to a building or a friend is in facebook.

Would you like to hear a person talking about hygiene and cleanliness if he doesn’t even use water to clean his donkey (try a synonym)? Now, do you understand where I am going? It all starts with this. If a coder is not convinced about keeping his variable names under check how can you expect him to try and understand concepts like “Separation of Concerns” and “n-tier” architecture? Even if they do theoretically understand, they will hesitate to practice it. The result is smelly, redundant spaghetti code.

The true takeaway of this post is to make my fellow coders understand the fact that keeping things simple and following patterns and practices is like “a stitch on time saves nine”. I know the fact that deadlines, peer pressures, and sometimes biased guidelines takes a toll on us, but that shouldn’t stop us from writing good, human readable code. Although machine executes it, but there is a reason why C# or any other high level language is in English not in binary. Leave your Visual Basic and VC++ 6.0 days behind you, be pragmatic, be objective, and be functional. Start now, its not that difficult, and you will see how your confidence develops, and you too can be cool!

Don’t listen to what I say, just give it a thought, and try the following links, and you will know what’s good and what’s not.

Naming Guidelines

No comments: