Notes from a fry-up lunch - A System of Names
Today we were discussing the wiki entry by Ward Cunningham on a System of Names
These were the thoughts that we had:
* Sometimes you need a name that doesn't mean anything - like MacGuffin
* The best names are the ones that you've arrived at with others that you're working with.
* Sometimes getting the name right completely changes the way that you think about things e.g. Changing the idea of a file being encrypted to a file being sealed
* Sometimes there's a terrible wrench every time you use a "properly" named object because what the object is/how it's used has changed since you named it. You need to be able to carry on changing the name of things throughout the process. In some languages, this is very difficult, if not impossible (Rails was mentioned as one).
* Ward Cunningham's suggestion that you use a thesaurus isn't a very good one - it betrays a misunderstanding of what language is, how it works. What are you going to use instead of "Master"? "Dominator"? "Dominatrix"?
* The canonical "misunderstanding" cases like "add" and "plus" can't be solved by just getting the right name. They can only really be solved by having some kind of convention of usage. It's not a list of names - it's a system.
For further information, contact Mark@agilelab.co.uk (07736 807 604) or Matt@agilelab.co.uk (07713 634 830)
Labels: A system of names, fry-up, object oriented programming, Ward Cunningham
1 Comments:
Just to clarify your reference to 'The canonical "misunderstanding" cases like "add" and "plus"', we were refering to questions such as whether a method changes its receiver (and returns nothing), or returns a change (or even returns the mutated receiver like Java's StringBuilder.append, smalltalk stylee).
Language can help here (toLowerCase() implies returning a change, whereas makeLowerCase() (or ruby's lower! ) imply a convention.
Also, there may be language support - e.g. Ruby's ! to mean dangerous (and often mutator). C has some form of static const function (is that right Paul?)
But you are right, in the end, a project needs to have its own local conventions -- getting the number of these right is critical (too many and the project becomes a kind of fortress resisting newcomers -- but not enough and the project is unlikely to have any sort of integrity or sense of self)
Post a Comment
Subscribe to Post Comments [Atom]
<< Home