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.
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.
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.
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”
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.
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
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.
- the technology will be evenly distributed by about then. ↩