Thursday, May 23, 2013

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.

No comments: