THE ART OF NAMING - THE DOS AND DON'TS OF SMART TERMINOLOGY IN SW
Software is a lot about naming things - and often this goes awfully wrong, resulting in high costs, not just financial ones. Proper terminology is the foundation of clear thinking, concepts, communication and business value. So what are the principles of naming and what are good/bad examples to learn from? I'm just starting. Please contribute!
- •Do: With naming, behave like an accountantDiligence and stringent and clear thinking help to create lasting conceptual frameworks. Good naming is the basis of a sound concept. Good naming provides a lasting skeleton for software. Any fuzziness in naming means that the subject matter isn't really understood. While the inventor might just about be able to understand what he/she meant by something, any successor will only be able to understand at high cost - more likely he/she will just muddle through until reaching another job position.
- •Don't: Never give similar names to different thingsDon't confuse matters by calling different things almost the same names. Think of userName, userID, userOID, id, etc. (To make matters worse, in larger system landscapes there are often multiple similar names for the same thing in addition)
- •Don't: Never use different names for the same thingNever use multiple different names for the same thing, be stringent and clear. Everything else creates confusion among anyone joining the team or maintaining the software. If you discover the existence of multiple names, fix the situation without delay. E.g. pick one of user, userID, id, uid, sessionowner, euser, whatever. If there is ever a real need to use multiple names be so diligent to maintain a well-known mapping table as a minimum.
- •Don't: ACNTINTRSTVLUEThat is supposed to be an "account interest value". Abbreviating identifiers to death is counter productive as typos go unnoticed, making code fail or fail to compile or making it impossible to ever find a document reference again that's misspelt. Neither reading time nor writing time is reduced with having fewer letters this way - on the contrary.
- •Do: Use the plural when referring to a population of itemsDon't name an array identifier as singular since it is really referring to one or many of the named entities. Use cars, never car. Alternatively, a suffix or prefix of "array" establishes the plural nature sufficiently: e.g. carArray.