Using Underscores, Hyphens or CamelCase in Naming Standards

I’ve been considering a small but vital problem in naming conventions in Networking. Namely, the use of underscores and hyphens in object names and devices. It’s a hot topic for argument when the time comes for corporate standards (and when Network Engineers have beverages in a public house). Now, I figure that there are three possible grammar options for making names – hyphens, underscore and CamelCase.

Technical Background

First, some technical concerns. The hyphen is part of the standard ASCII character set and has been adopted and managed in software since the earliest days. Support for hyphen in DNS and NetBIOS was included and working in the early standards. The underscore is not always handled correctly and is not be correctly recognised in DNS or NetBIOS names. Today, DNS and NetBIOS (and their apparent successor technologies Active Directory) are updated to support the underscore because so many people did it anyway (and wondered why MS networking didn’t work properly). There are many applications, firewalls, load balancers etc that still do not handle the underscore correctly and therefore should not be used for another decade or so in networking. 1 For other IT discplines, the use of hyphen or underscore has few technical limits.

Some History

It’s my belief that the use of the hyphen came from programmers who create variable names that are often in upper case. When mashing the shift key for CAPS during typing, it’s considerably easier to keep the shift key pressed and use an underscore. A secondary benefit/agrument is that underscores are more readable since they do not obscure the text like a hyphen. Thus DEVICE_RACK_LOCATION is more readable than DEVICE-RACK-LOCATION. Or device_rack_location is more readable that device-rack-location but harder to type.

Some Alternatives

Using Caps text in networking is a useful convention for indicating that something is a configured term. In a Cisco IOS Service Policy, it’s reasonably common to type user defined names in caps.

In more recent times, the rise of CamelCase has changed the dynamic with the use of capital characters as delineators and no spaces. Thus “DeviceRackLocation” is quite readable. CamelCase kinds of breaks down on certain names e.g. in naming a collection Microsoft AD ports “MSPortSpam” isn’t instantly intuitive because the caps “MS” run into the “P”

Comfort

Alternates such as MS-PORT-SPAM or MS_PORT_SPAM or even MS_Port_Spam (if you don’t mind lifting your fingers off the shift key) arguably work better for this case. Now, lets not underestimate how easy it is tp type these characters. The underscore requires, on most keyboards, the shift key.

A more minor point, when using a click or highlight selection in terminal window to copy text, not all terminal clients regard _ or – as part of the words. This annoys me greatly and supports the use of CamelCase.

Consistency.

At the end of the day, the choice of between hyphens, underscores or CamelCase is a fruitless discussion. Different people will prefer one or other for as a personal preference and once your muscle memory or mental slot for naming is fixed (usually early in your career) then it’s hard to change.

One thing is for sure, people will only adopt a standard that makes sense and is easy to use unless forced to do something else. The only way to enforce a standard is to have a process to regularly audit, check and validate all names and have penalties in place for people who do not follow the standards. Getting some sort of consensus at the start helps but isn’t

Length

I would make the following suggestions: * hyphens are best when using lower case names because it’s easier to type. * underscores are better when using CAPS for names since it’s easier to type. * CamelCase is best in most cases because it’s more obvious that it’s a variable and it easier to copy/paste in more circumstances.

The EtherealMind View

A bad naming standard is a better than no standard. But not by much. This is a start though.


  1. the technology will be evenly distributed by about then.
  • http://showbrain.blogspot.com Ben Story

    Personally I use hyphens, but either hyphens or underscores work for my main reason of using hyphens.  My main reason is that it is easy to use regular expressions to script things based on parsing names with hyphens or underscores.  CamelCase is hard to parse for exactly the case you highlighted above of MSPortNumber where there are multiple capitals involved in the name itself.

    • Ryan Malayter

      Major props for this one, noting is worse than not being able to edit config files en masse because of inconsistent case or white space usage! I usually track down the offender and make him/her update all the files by hand… even if they’re no longer with the company.

  • http://twitter.com/xanthein Jon

    Another point is that DNS is case-insensitive.  For this reason I generally stick to lower-case only with hyphens.

    Another thing that always amazes me with naming standards is the number of people who want to weigh in with their opinion even if it isn’t something that will directly affect them!

    • Romans Fomicevs

      CamelCase is not that good to my mind. It is hard to parse with scripts and it is hard to read, when you accidentally have to read them in tolower() or toupper() mode. So we are left with two options only. 
      However, which is more important is naming standards as such – how do you name your devices, what information you put into it’s name (type, model, location? and in which sequence) and how you shorten all those names, because you are hitting device name limitations quite often :P

  • http://twitter.com/silverbenz Ben Johnson

    I’ve also seen CamelCase used in a slightly different format, where the initial word/phrase/letter-group is lower-case rather than upper-case, eg. msPortSpam.  It’s a minor variation which would help in this particular instance but still falls a little short, for the same reason as Greg states above, where an acronym is included in the middle of the sequence, eg. myOSPFilterRule

  • Pete

    After dealing with this battle in what seems like forever (as many of you have as well), I’ve found that the best delimiter is… no delimiter.  I know, it sounds crazy, but haven’t you seen, or come up with some great naming nomenclature, and agreed to whatever delimiter, only to find that you can’t remember where the delimeter goes?  Yeah, if needed, I’m partial to hyphens, but those in the *nix camps tend not to like them for various reasons.  Underscores have a much more dubious honor I think it totally messing up infrastructures, but thats anecdotal observations rather than imperical evidence.

  • Sam Silvester

    Just adding another vote for no delimiter.

    Definitely have a standard, but in terms of networking equipment I like a functional indicator (cor, bdr, lns, pe etc), and an index (1, 2, 3 etc).

    Then use DNS subdomains for each ‘site’ e.g:

    bdr1.adl1

    The other things that I’ve found work are:

    - Don’t use leading zeros (e.g. don’t do bdr01.lax01) – two good reasons:

    1) You run out of space, leading to strange things like ‘ce101′ and ‘ce07′, which can increase error rates and make it harder to regex against.

    2) People don’t ‘say’ numbers over the phone – they’ll say ‘core one’, not ‘core zero zero one’. More opportunity for confusion – and for what benefit?

    - Don’t use hyphens. People don’t say those on the phone either.

    - Don’t worry about including things like device model or vendor in the name for devices – you’ll change the device, or the model. Additionally, for the paranoid you’ll be giving free hints to anybody that may be looking into your network.

    - Finally (especially about locations e.g. ROOM_SUITE_RACK etc) – I like to go with whatever is likely to be familiar to the majority of people. Our local incumbent Telco goes with ROOM/SUITE/RACK/RU – so we’ve done the same in all of our sites, and it means when contractors come in, they’re in familiar territory.