The importance of naming conventions for method and variable names

After an eight year gap, a small post to get myself back into the swing of things by talking about something I feel is fundamental when programming on any reasonably sized project: consistent use of naming conventions.

So with no further ado (a long post may well become no post), here's my list of important rules:

1. Tense is very important ensure that method names (and event names for languages that support events) properly denote temporal order.  So, past tense for something that has happened, future tense for something that will happen (or rather, is about to happen) and present tense for something that is happening.
2. No abbreviations in names.  One persons obvious abbreviation is another's gibberish.  Universally understood abbreviations (such as ID) are probably allowable, but these are really few and far between.
3. Following on from the no abbreviations rule above, it should be noted that method and variables names should not include noise words.  If something is obvious (perhaps from the class usage), there's no need to include it in a name.
4. Follow the idioms of your preferred language or library.  Well designed languages or libraries usually have well designed naming structures.  While you or I may not not always agree with all their design decisions, it's usually a good idea to go along with them, so that there's a strong feeling of cohesion between core and extension APIs.
5. Prefer to structure method names to begin with verbs.  I can't entirely put my finger on why I like this, but code always seems to read more fluently when this rule is followed.

I'm tempted to elaborate on this post at some point, so who knows?  In eight years time I might follow up.

Laying My Cards on the Table

I'm not entirely sure about the kind of things I'm inclined to write about, so I thought I'd take a moment to at least lay my biographical cards on the table, so to speak.

I'm a thirty eight year old computer programmer, living in London with my wife and one year old daughter. I work for an engineering company writing CAD software in C++ which I suspect will come up in one or two future postings (if I post at all, that is).

Years ago I started my programming life by writing Cobol programs. In some ways, I look back on programming in Cobol with a good deal of nostalga. I found it to be a pretty well structured and readable language. In fact, I find the C++ code I write is starting to remind me of old Cobol code. Hmmmm. Via a couple of meanderings into 8086 assembler (yuck!) and DEC-10 Macro assember (yummy!), I wound up programming in C for years and years on Unix systems and eventually C++ on various incarnations of Windows NT, starting with version 3.51.

In 2001 I discovered GNU/Linux and, for home use, I've been pretty much hooked ever since. Every now and then I try to convince my bosses that we should free (in the GNU sense) some of our software. No joy yet, but you never know....