Whenever you create an object you have to find a meaningful name.
While renaming later in modern IDE’s is no problem at all you should not pick the first name which comes to your mind.
Imagine you have an external fraud detection web service and it will return a ‘hit’ or ‘miss’. How do you name this object? HitOrMiss maybe (since this is the representation you get from the webservice) ? It might describe the problem at hand. If you go with this name it will dripple down through all layers. The domain model, the dto’s, services and more will now reference to this object (and create their own derivates for it). Your colleagues which code up other parts of the system will refer to it and create their own variants of the name (like structure for web pages). The wrong name is now all over your code.
So much for refactoring in your IDE. You will never catch all the places automatically where the wrong name was used.
While it seemed lost time discussing the ‘right’ name for 5 minutes in the beginning it saves you much more time afterwards. Of course you might get also confused a couple of weeks later remembering what this thing really does and what it is used for.
Make sure you take time in naming your objects. A wrong decision can do some harm to your code. The later it turns out that the name was not correct the much more expensive it becomes to correct this mistake. If you are not really sure how to name it, talk to your colleagues and discuss the name. A second opinion can not hurt.
Maybe FraudDetectionResult would have been a better choice.
5 Responses to “Name your objects right”
Leave a Reply
Additional comments powered by BackType
Quoted for truth.
Same applies for other programming constructs you happen to use of course.
The original Logo programming language used “TO” keyword as a prefix its functions. I think that encapsulates well the idea how one should name functions and methods. The idea also helps you to maintain some clarity.
In case of variables one should take the scope of a variable in count. The longer the scope, the more descriptive the name should be. If the scope is short, a simpler name will do.
I gathered these ideas from “Clean Code” by Martin and “Code Complete 2″ by McConnell. So far following them has worked out just ok.
“Clean Code” is a pretty good book. My management bought into it and help people implementing our own variation.
New blog post: Name your object right http://bit.ly/b7fAXE
This comment was originally posted on Twitter
Good point Olli.
IMHO a good data modelling (and skilled modeller) could face and hopefully solve this issue. The “HitOrMiss” sugestion describes a finite domain, where as “FraudDetectionResult” is a more or less business object. The try to bring this all in alignment with an overall data modell let you detect quite early that something is wrong with “HitOrMiss”.
Regards
Rayk
Name your objects right – http://su.pr/2tJk6F
This comment was originally posted on Twitter