Sunday, November 25, 2012

A Note on Naming

I was reading some code the other day, and found myself struck once again as how deep the influence of someone’s first, or perhaps favorite, language is upon their coding style. Usually when we say this, we think of the overall structure of the code: exception handling; loop structure; the shape of the class hierarchy. These are all true, but in this particular case it was the class naming convention that was an issue: each class name contained an embedded portion of the domain hierarchy.

For example, if we were writing a system to handle the warp drive component, each class would be prefixed with WarpDrive, e.g., WarpDriveWarpCore, WarpDriveDilithiumCrystals etc., even if the package holding all of the classes was gov.starfleet.starship.warpdrive. That is, the fact that it is part of the warpdrive is already explicit from its location in the domain hierarchy.

 I have also seen this in databases in which a column name has the name of the table (or more likely a shortened version of the table name) prepended to it. For example, the patient table might have columns named patient_ID, patient_first_name, patient_last_name. I used to do this myself but was broken out of the habit by frameworks such as rails and hibernate which just works so much easier if the ID column is called simply ID.

 Certainly this is not the worst programming practice possible, just one that makes things a little more redundant while, if anything, reducing clarity: class names become longer but are more easily confused/misremembered because the names have so much in common. I have nothing against redundancy per se because I think it often adds clarity, but when it doesn’t I just find it redundant.

 I know people will find this amusing coming from me of all people since I come from a LISP space I am very, very fond of long, descriptive names -- I guess have now found an exception to my normal longer names are better rule.