Naming conventions and how irritating some are.

January 13, 2007

Alright (is that actually an English word? Not s’pposed to be as far as I can remember. Oh well) . Anyway, this has been a sore issue with me ever since I’ve had to read other people’s code and it is possibly the most irritating thing I have ever come across in programming – bad naming conventions. Seriously, what the hell is gts_fwd_A? And what about _tys? How are they are s’pposed to make any sense to a normal human being? One could swear that the world was filled a bunch of unimaginative and illogical people *nods* and that they all managed to get their grubby hands on a computer and generate insensible code *nods again*. I’ll admit that in some instances, very very very very very rare instances, a few of these bad naming conventions are necessary but these are special cases and as such people should steer clear of these conventions to the best of their abilities.

In any case what I’m gonna do is give a bunch of guidelines on good (in my experience at least) naming convetions and in the process mention those which are bad and bloody irritating.

1: First off, the most important rule is to make sure that the names mean something. For god’s sake don’t go calling a text box bob! I’ll admit that if you’re just testing an idea, or a piece of code that you’ll never actually use, then this is ok but only if noone will never ever see it again once you’ve used it. If there is any doubt whatsoever that the code might be seen by another human being, or yourself, sometime in the future then make sure the name means something! There is nothing worse than going through code and having to memorize and familiarize yourself with a bunch of names which make no bloody sense. It’s damned confusing!

2: Association and consistency! For example, if you work with forms and multiple windows alot make sure that the controls you are working with have decent names. Say for example you are working with a text box, then name the text box TB… . This way as soon as you see a variable with TB at the start you’ll know exactly what it is. If you’re working with controls which have similar abreviations then just add a letter someplace so that it still holds meaning. Like check boxes and combo boxes will be prefixed by CHB and CB or CB and COB. It’s really simple and makes life alot easier. Also, make sure that you use the same abbreviations for all controls of the same type so that you don’t confuse yourself.

3: Along the same lines, make sure that the name matches the purpose of the control/class/object and describes it. If you have a label with the text ‘Name:’ then name it LName. It makes a huge difference when working with it in code. If you have a bunch of controls which have the same text but are in different windows or tabs or group boxes then name them according to the window or tab or group box. So if two labels with the text ‘Name:’ are in two tabs ‘Personal’ and ‘Work’ then name the LPersonalName and LWorkName so that just by looking at the name you can determine exactly which label is being referenced.

4: Don’t use bloody underscores! I cannot tell you how crap underscores truly are! (Oh, in case you didn’t know, there are instances when underscores must be used but most people will never come across them so just pretend these special cases don’t exist.) Underscores should be avoided at all costs. The reason being that they are stupid looking and make names much longer than they have to be! ‘That’s all?’ you ask, and the answer is yes. The phrase ‘pet peev’ doesn’t even cover it. The worst is when people use underscores as the first character in a name. For god’s sake why!?! It doesn’t make any sense! Why have the underscore there at all? Why not just omit the bloody thing? Another thing, I have lost track of how many beginners emulate their predecessors (the folks who started programming back when the Internet was still unknown) by using underscores as often and as frequently as possible. They just can’t think for themselves! *pant* Lets just leave it at that.

5: Use capital letters. It’s really very simple. If the name has multiple words in it then start each word with a captial letter so it is more legible and the words are easily differentiable. For example, usebloodycapitals becomes UseBloodyCapitals. Also, replace underscores by capitalising the first letter after each underscore!! That way the name is shorter and looks better *nods firmly* I don’t know why but a lot of people use lower case letters together with underscores and end up with ugly bloody names which are bloody long and bloody irritating. use_bloody_capitals changes to become the nice and classy UseBloodyCapitals. See. Common sense goddamnit!

Argh. These are just a few of the many guidelines which should be followed, not because they must be followed but because they make sense! In any case, using these guidelines takes a bit of time to get used to and everybody has their own way of doing things but over time you’ll eventually get into the habit of things. Ultimately, you’ll end up doing things in your own special way but, whatever you do, try and stick to these guidelines because they’ll make your life and the live’s of those who read and use your code much easier. Not too mention the quality of your code will be alot better.

So say we all!

Advertisements