A comment by a colleague on my last post on 'relations' - chuckling at the question "What on earth is a 'parent-child relation'?" prompted a post on one of my other naming pet hates - namely the mis-used concept of Parent-Child to denote hierarchy.
Over ten years ago I wrote a tree handling routine that needed to delete sub-nodes of a particular node and the method started off being called Node.DestroyChildNodes() which, at the time, I thought would be pretty cool to rename to Node.KillChildren() to reflect the concept of eliminating the children. Over the years I became more pedantic about naming, primarily inspired by my mentor who was and is extremely particular about naming. This person had an interesting academic background and his degrees in Theology, Psychology and Electrical Engineering made him interesting to deal with. He was working as an architect on a project and I overheard a discussion he was having with a developer that went something like this...
Architect - "Did this account fall pregnant?"
Developer - "Er... no" (I don't understand the question look on his face)
Architect - "Did this account go into labour?"
Developer - "Er... " <long pause> "No"
Architect - "Was this account inseminated by another account"
Developer - "I don't think so" (some language barrier here)
Architect - "Did this account go to hospital and, after a long labour, give birth to this (other) account?"
Developer - "No. What on earth are you talking about?"
Architect - "If this account didn't physically give birth, or contribute is sperm to that account, WHY THE <expletive removed> DO YOU CALL IT THE 'PARENT' ACCOUNT?"
Since then, the developer made sure that he only used parent and child when referring to real people, as parents, and their children.
So if it is not correct to use parent-child except in cases where there are actual people involved who have a legal and physical association, what should be used to denote hierarchies? The simplest and most generic would be to use subordinate which the dictionary defines as 'One who stands in order or rank below another'. The shorthand of subordinate is sub and is something we use often in English as in subtitle, sub-paragraph and so on. If sub is the 'child', what is the 'parent'? From a rank perspective, a choice could be 'principal' but more generically I prefer to use 'superordinate', which the dictionary defines as 'Of higher rank, status, or value'. Although superordinate may be a little bit obscure it is used in English (superscript) and has a convenient shorthand - namely sup (which if misinterpreted to be 'superior' is not to bad.
Using this naming, a table that stores a hierarchical structure may have the fields 'Id', 'Name' and 'SupId' (instead of ParentId). My tree routines would also read better - instead of DestroyChildNodes() I would have DestroySubNodes(), which reads well; I would also have a property called SupNode, that would return the superordinate node.
Using sub and sup is the easy, generic solution, but if you think about it more there are other names that can be used in different circumstances such as...
| Superordinate | Subordinate |
| Predecessor | Successor | Used if the time dependency is critical |
| Provider | Dependant | Used in true dependency relationships |
Can you think of any more to add to this list?
It is important in both design and implementation that we name things well and that they make sense. All too often business hands something over to IT and by the time it comes back it has been abstracted, generalized renamed and confused.
Imagine the scenario when dealing with a user talking about a medical aid system where a person has dependants...
Developer : "When you click here the child nodes are removed"
User: "Why not the spouse node as well?"
Developer: "There is no 'spouse' node"
User: "There is, two children and one spouse"
Simon Munro