Stoop 422-naming idioms
Download as PPT, PDF1 like365 views
This document discusses naming conventions and standards for Smalltalk code. It recommends that names should reveal intention, follow standard protocols, and use intention-revealing selectors. Specific naming guidelines are provided for variables, methods, classes, parameters, and temporaries. Names should indicate roles rather than types where possible. The document emphasizes that naming is important for communication and maintaining code quality. It concludes by recommending the book "Smalltalk Best Practice Patterns" as a useful reference.
Stoop 422-naming idioms
- 1. Stéphane Ducasse 1 Stéphane Ducasse stephane.ducasse@inria.fr http://stephane.ducasse.free.fr/ Naming Smalltalk Patterns
- 2. S.Ducasse 2 Coding Standards Mainly from Smalltalk Best Practice Patterns by K. Beck Excellent Must read!
- 3. S.Ducasse 3 Coding Standards • Standards • improve communication • let code be the design • make code more habitable • change
- 4. S.Ducasse 4 Coding Standards for Smalltalk • Variables have no types • Names can be any length • Operations named with keywords • Pretty printer
- 5. S.Ducasse 5 Names • Names should mean something. • Standard protocols • Object (printOn:, =) • Collection (do:, add:, at:put:, size) • Standard naming conventions
- 6. S.Ducasse 6 Intention Revealing Selector • Readability of message send is more important than readability of method • Name should specify what method does, not how. • aDoor open • and not • aDoor putPressureOnHandleThenPullWithRotation
- 7. S.Ducasse 7 Examples ParagraphEditor>>highlight: aRectangle self reverse: aRectangle If you would replace highlight: by reverse: , the system will run in the same way but you would reveal the implementation of the method.
- 8. S.Ducasse 8 Examples If we choose to name after HOW it accomplished its task Array>>linearSearchFor:, Set>>hashedSearchFor:, BTree>>treeSearchFor: These names are not good because you have to know the type of the objects. Collection>>searchFor: even better Collection>>includes:
- 9. S.Ducasse 9 Instead of: setTypeList: aList "add the aList elt to the Set of type taken by the variable" typeList add: aList. Write: addTypeList: aList "add the aList elt to the Set of type taken by the variable" typeList add: aList. Name your Method Well
- 10. S.Ducasse 10 setType: aVal "compute and store the variable type" self addTypeList: (ArrayType with: aVal). currentType := (currentType computeTypes: (ArrayType with: aVal)) Not precise, not good computeAndStoreType: aVal "compute and store the variable type" self addTypeList: (ArrayType with: aVal). currentType := (currentType computeTypes: (ArrayType with: aVal)) Precise, give to the reader a good idea of the functionality and not about the implementation Name Well your Methods
- 12. S.Ducasse 12 Method Names • If there is already a standard name, use it otherwise follow these rules. • Three kinds of methods • change state of receiver • change state of argument • return value from receiver
- 13. S.Ducasse 13 Change State of Receiver • method name is verb phrase • translateBy: • add:
- 14. S.Ducasse 14 Change State of Argument • Verb phrase ending with preposition like on or to. • displayOn: • addTo: • printOn:
- 15. S.Ducasse 15 ReturnValue from Receiver • Method name is noun phrase or adjective, a description rather than a command • translatedBy: • size • topLeft
- 16. S.Ducasse 16 Method Names • Specialized names for specialized purposes. • Double-dispatching methods • Accessing methods • Query methods • Boolean property setting • Converter methods
- 17. S.Ducasse 17 Accessing Methods • Many instance variables have accessing methods, methods for reading and writing them. • Same name than the instance variables • Accessing methods come in pairs. • name, name: • width, width: • x, x:
- 18. S.Ducasse 18 When to use Accessing Methods • Two opinions: • Always, including an object’s own instance variable • lazy initialization, subclassing is easier • Only when you need to use it. • better information hiding • With the refactoring browser it is easy to transform the class using or not accessing
- 19. S.Ducasse 19 Query Method • Methods that return a value often describe the type of the value because they are noun phrases. • Query methods are not noun phrases, but are predicates. • How can we make the return type clear? • Provide a method that returns a Boolean in the “testing” protocol. Name it by prefacing the property name with a form of “be” or “has”- is, was, will, has
- 20. S.Ducasse 20 Testing Methods • Prefix every testing method with "is". • isNil • isControlWanted • isEmpty • hasBorder
- 21. S.Ducasse 21 Converting Method • Often you want to return the receiver in a new format. • Prepend "as" to the name of the class of object returned. • asSet (in Collection) • asFloat (in Number) • asComposedText (in Text)
- 23. S.Ducasse 23 Simple Superclass Name • What should we call the root of a hierarchy? • Complex name conveys full meaning. • Simple name is easy to say, type, extend. • But need to show that subclasses are related.
- 24. S.Ducasse 24 Simple Superclass Name • Give superclasses simple names: two or (preferably) one word • Number • Collection • VisualComponent
- 25. S.Ducasse 25 Qualified Subclass Name • What should you call a subclass that plays a role similar to its superclass? • Unique name conveys most information • Derived name communicates relationship to superclass
- 26. S.Ducasse 26 Qualified Subclass Name • Use names with obvious meaning. Otherwise, prepend an adjective to most important superclass. • OrderedCollection • UndefinedObject • CloneFigureCommand, CompositeCommand, ConnectionCommand
- 27. S.Ducasse 27
- 28. S.Ducasse 28 Variables: Roles vs.Types • Types are specified by classes • aRectangle • aCollection • aView • Roles - how an object is used • location • employees • topView
- 29. S.Ducasse 29 Role Suggesting InstanceVariable • What should you name an instance variable? • Type is important for understanding implementation. But class comment can describe type. • Role communicates intent, and this harder to understand than type.
- 30. S.Ducasse 30 Role Suggesting InstanceVariable • Name instance variables for the role they play. Make the name plural if the variable is a collection. • Point: x, y • Interval: start, stop, step • Polyline: vertices
- 31. S.Ducasse 31 Type Suggesting Parameter Name • Name of variable can either communicate type or role. • Keywords communicate their parameter's role, so name of variable should give new information.
- 32. S.Ducasse 32 Type Suggesting Parameter Name • Name parameters according to their most general expected class, preceded by "a" or "an". If there is more than one parameter with the same expected class, precede the class with a descriptive word.
- 33. S.Ducasse 33 Temporaries • Name temporaries after role they play. • Use temporaries to: • collect intermediate results • reuse result of an expression • name result of an expression • Methods are simpler when they don't use temporaries!
- 34. S.Ducasse 34 Conclusion Names are important Programming is about communication intention … Read the book: Smalltalk Best Practice Patterns Even if you will program in Java or C#! When the program compiles this is the start not the end…