Smalltalk has very few rules about naming classes, variables, methods, categories and protocols. The few that do exist were quickly covered in Chapter 4—The Smalltalk Language. Our interest here is in the conventions which govern the way Smalltalk programmers name their classes, variables and other entities. These conventions have evolved over time to make Smalltalk code read in a particular, almost English- like way.
Variables
To begin with, you should always follow the rule (even though it's not completely enforced by the system) that global variables, pool variables and class variables all start with a capital letter, whilst instance and temporary variables start with a lower-case letter. After that, try to make your variable names as descriptive as possible.
Remember that variable names can be as long as you like. You might want to try to include something about the function of the variable, as well as the type of object it is expected to contain. For example, oc cup iedRec tangle, labelText, examResults . The last example uses a common convention to indicate a collection—it's a plural—a collection of examResult objects.
If want to name a variable which holds a boolean state, use something like IsBig.wasConverfced, hasBeenEdited. Using these kinds of name allows you to write classic Smalltalk expressions such as:
Coding in Smalltalk
occupiedfiectangle hasBeenEdibed ifTrue:
["Do Something"]. In this case, hasBeenEdited is the accessing method for the instance variable called hasBeenEdited in some class of which the object occupiedRec tangle is an instance.
Parameters
A common convention for naming parameters in method definitions is to use the name of the class of the object you expect to be passed, prefixed with 'a' or 'an' as is appropriate. For example, anOrderedCol lection, aDictionary, aString. If a parameter in your method could be an instance of several different classes, use the lowest common superclass. For example, aCollection, or in the extreme, anObject. The latter is not as meaningless as it may seem if it is communicating the fact that an object of any class may be passed as a parameter.
Method Names
Just like variable names, you should try to make method names (or selectors as they are technically known) descriptive of their purpose. There is no limit on length, so again you should use as long a name as you need (within reason of course). Browsing the class hierarchy will show you that there are some very long method names indeed out there! Methods whose only purpose is to access variables should be named after the variable they access. For example, if you have an instance variable called size, the method which returns its value should be called size , and not returnSize, getSize, giveSize or anything else. Similarly, the method which sets its value should be called size: , not setSize: or anything like that.
In a similar vein, try also to make method names declarative rather
than imperative. In other words, it is better to use totalArea than compute TotalArea. This makes the method name communicate the kind of value it returns. This is important when you want to cascade messages. Compare the following two expressions:
CricketPitch area asSquareMetres.
CricketPitch giveArea convertToSguareMetres.
At the moment it may seem a subtle distinction, but the first expression reads much more clearly to Smalltalk programmers than the second. If
you really want to use words like 'convert', use the past participle instead—convertedToSquareHetres.
When naming a method which takes several parameters, try to create a name which conveys the purpose and if possible the type of each parameter. For example:
PaintBox drawLineFrom: x to: y
usingPen: aPen inColour: ftred. Note that in this case, we broke the rule about making method names declarative (drawLineFroxn... instead of lineFrom...). This is because we are interested in the side-effect (the line getting drawn) and not the return-value of the method.
Finally when naming a method, think of the service it provides, not the way it provides it. In other words name the method after the interface not after the implementation. Doing this will avoid revealing things about the way your implementation works by the way you name your methods.
Classes
Remember that class names are really global variables, and so you should follow the same rule that they start with a capital letter. Just as before, the real intent should be to communicate the purpose of the class. However, you may also wish to communicate something about the class hierarchy, if that is important. For example OrderedCollection is a subclass of Collection. You might go on to create a subclass called OptimizedOrderedCollection (just as an example). This naming convention is not always necessary or desirable though—it's a matter of judgement. For example. Set is also a subclass of Collection, but in this case the word 'Set' communicates more about the purpose of the class than any more contrived name ever could.
Avoid the temptation to prefix class names with your initials, the project name or your company name. Although it might seem that this would make them easier to separate from the system classes, it actually just makes them difficult to distinguish from each other. You should be
aiming to integrate your classes into the system anyway. Categories and Protocols
Categories and protocols exist to help you organise your classes and methods. Use names which facilitate this. Remember you can include
Coding in Smalltalk space characters. Some people like to use prefixes which indicate who the classes in a category were written by. This is acceptable in category names, since they don't appear in.your code. Others like to indicate which project the category was written for. The categories in the class library generally use a two-level naming scheme, and it's worth considering whether to adopt this for your project. For example,
Server-Views or Framework-Datastore.
We looked previously at the 'standard' protocol names which the classes in the system library use. Names like accessing, updating,
displaying and private are absolutely fundamental to the
Smalltalk idiom. If you use any of the naming conventions discussed here, use this one. It is possibly one of the biggest contributing factors to making your code readable by others. However, not only should you use the names, you should use them properly. Don't put anything other than methods which provide access to instance variables in accessing for example. If a method is private (to be used only by you) put it in the private protocol. When you need to create new protocol names, try to name them with the task of either you or someone else trying to understand your code in mind. A good guideline to follow is to use present participles as protocol names—words which end in '-ing'. For example, calculating or printing.