Smalltalk and Object Orientation: an Introduction - Free

24. Smalltalk Style Guidelines
24.1 Introduction
Good programming style in any language helps promote the readability, understandability and clarity of
your code. In many languages there are established standards to which many people adhere (sometimes
without realizing it). For example, the way in which a C or Pascal program is indented is such a
standard. However, style guidelines which have evolved for these proc edural languages do not cover
many of the issues which are important in Smalltalk. These are issues relating to classes, instances and
methods. As non-object oriented languages do not have these concepts, they do not have standards for
dealing with them.
Of course you should not forget all the pearls of wisdom and programming practices that you have
learnt using other languages. Just as in any other language there are a number of acknowledged bad
practices (which are not specific to Smalltalk), for example, the use of global variables! In this chapter
(as in the whole of the book) we will assume therefore that you do not need to have the basic concepts
explained, instead we will try to concentrate on those style issues which are specific to Smalltalk.
The re mainder of the chapter is structured in the following manner: Section two considers style
issues associated with variables including temporary variables, instance variables as well as class, class
instance and pool variables. Section three provides some gu idance on the use of classes within
Smalltalk. Section four considers methods, their naming, use and code placement within methods.
Section five discusses how to name message protocols for both instance and class methods.
24.2 Variables
24.2.1 Naming variables
In Smalltalk variable names such as t1, i, j, or temp should rarely be used. Instead variable names
should either be descriptive (known as semantic variables) or should indicate the type of object which
the variable will hold (known as typed variables). Which app roach should be chosen depends on both
personal style and the situation in which the variables are being used. Instance and class variables, for
example, tend to have semantic-oriented names, while parameters to methods often have typed names.
The semantic approach has the advantage that less needs to be assumed about what the variable will
be used for. Since subclasses can inherit instance and class variables, the point at which they are defined
and the point at which they are used may be very remote. Thu s any contextual meaning and
commentary, provided with their definition, will have been lost. Examples, of semantic variable names
include:
score
currentWorkingMemory
TotalPopulationSize
The typed approach is often adopted for parameter names as it is ea sier to see what type of object is
required as an argument to a method. For example:
add: anObject ifAbsent: aBlock
at: anIndex put: anObject
Although some methods mix the use of the two, for example: at: key put: anObject .
195