14 December 2006 - 16:56Clean code, meaningful names, black-boxes, glass-boxes

I was thinking about the good practice of using names for classes and methods which describe what they implement and I came to the conclusion that one benefic side effect of this practice is that it promotes to a certain extent the principle of black-boxes. Meaningful names and clean code discourage a developer from peeking into the black-box (a method on a class for example) to see what it actually does. Methods that only do what their name states (such as authorizeCreditCard which just authorizes a credit card and doesn’t also commits the purchase order) also enforce the black-box mechanism. Transparent development could be regarded as one way to avoid cluttering business logic classes with outside concerns (such as security, transactionality, etc…).
I find that it helps to have meaningful names closer to the business process, in a sense they should be readable by business people. A class which CAN be read by a business person has a bigger chance to be aligned with the process it implements. When the class and method names used in the code start deviating from names used by business analysts it is a good indication that you should re-factor it in order to align it better with the business process.
When dealing with real black-boxes (i.e. interfaces) meaninful names are actually mandatory, bad names will end up obfuscating the process that these interfaces abstract.

P.S. I know I should have dropped this post in the ‘Stating the obvious’ category, but I don’t have such a category ;-).