naming
DESCRIPTION
Naming. General. Highly important Understandability without delving into details Classes – Nouns File Account SymbolTable Methods – Verbs open() withdraw() lookup(). General (Cont.). Popularity Scope Rule of thumb: No good name -> Redesign the class - PowerPoint PPT PresentationTRANSCRIPT
1
Naming
2
General
•Highly important
•Understandability without delving into details
•Classes – Nouns• File• Account• SymbolTable
•Methods – Verbs• open()• withdraw()• lookup()
3
General (Cont.)
•Popularity
•Scope
•Rule of thumb: No good name -> Redesign the class
•Avoid hiding of fields with variables
•A good metaphor may help: Figure, Page
4
Types •Nouns: Figure, Account
• Sometimes –er suffix: Formatter, Loader
•Popularity => Simple name• Frequent usage: typing a variable• Frequent usage: superclass
•Communicate similarities & differences• Add a prefix to the superclass
class TextFormatter extends Formatter { ... }
•Avoid “Object” in class names
•Single form for enum typesenum Pet { CAT, DOG }
5
Interfaces vs .Classes
•Interfaces will usually be a popular type
class ColoredFigure implements Figure { ... }
•-able is a common suffix for interfaces• Denotes a mixin-like protocol unit
•If both interface & concrete class are popular
abstract class AbstractFigure implements IFigure { ... }
class Figure extends AbstractFigure { ... }
6
Common Naming Schemes
InterfaceSuperclassRoot ClassSub Classes
FigureAbstractFigureDefaultFigure
FigureAbstractFigureConcreteFigure
FigureColoredFigureResizableColoredFigureFixedColoredFigure
IFigureAbstractFigureFigure
ResizableFigureResizableFigure
7
Methods
•Verbs: paint(), remove()
•boolean setters/getters• isVisible()• setVisible(boolean)• show(), hide() // More explicit
•Getters• getX()• x()
•Setters• setX(int)• x(int)
8
Variables•result•results•count, n•curr, each•i, j•arg•List<Message> messages•Map<String,String> addressFromName •that•lhs, rhs•iconA, iconB•Event event; Painter painter;•Event e; Painter p;•isEmpty; // Better than: if(!notEmpty) ...
9
<hungarian.notation>
10
Hungarian Notation is Bad
•Prefix specifies the type/stroage of the variable
•C• ulDistance = Unsigned Long• bEnabled = Boolean • paulData = Pointer to Array of Unsigned Long• szName = Zero terminated String
•Java• pX = Parameter• fY = Field (sometimes “m” for Member)• sfZ = Static Field
•Considered outdated (or even evil)• Overly verbose• Obviated by: smart IDEs, short methods/classes
11
Hungarian Notation is Great
•Prefix specifies “pseudo subtype”
•Pseudo subtypes examples:• Integers: Row vs. Column• Integers: Dollars vs. Cents• Strings: text vs. HTML
12
Is Address HTML-ed?
String str = person.getDetails(“address”);...
String adr = str;
...
record.setField(“location", adr);
...
String address = record.getField(“location"); ...
out.println(“Send to: <i>” + address + “</i>”); // Did we remember to call htmlEncode() ??
13
Hungarian Notation to the Rescue
Let’s apply the following convention:
•Strings coming from the user are considered text• Must be stored in variables prefixed with “t”• The same goes for database columns
•htmlEncode() translates a “t” prefix to “h”• Strings returned from htmlEncode() are considered HTML• Must be stored in a variable prefixed with “h”
•Assignments allowed only if prefixes match
14
Is tAddress HTML-ed? String tStr = person.getDetails(“address”);
...
String tAdr = tStr;
...
record.setField(“tLocation", tAdr);
...
String tAddress = record.getField(“tLocation");
...
out.println(“Send to: <i>” + tAddress + “</i>”); // Clearly, tAddress was not htmlEnocde-d
15
Rename: tAddress => hAddress String tStr = getOrderDetails(“address”);
...
String tAdr = tStr;
...
record.setField(“tLocation", tAdr);
...
String hAddress = record.getField(“tLocation"); // violation of our convention !!
...
out.println(“Send to: <i>” + hAddress + “</i>”);
16
Correct Code – All Prefixes Match String tStr = getOrderDetails(“address”);
...
String tAdr = tStr;
...
record.setField(“tLocation", tAdr);
...
String hAddress = htmlEncode(record.getField(“tLocation"));
...
out.println(“Send to: <i>” + hAddress + “</i>”);
17
</hungarian.notation>
18
</naming>
19
Eyetracking
20
Benefits of Narrow Code
•We don’t read stuff on the right-hand side•Stacktrace•Debugability of if statements•Debugability of return values•Explaining variables
•=> Prefer tall, narrow code• Over short, wide
21
Fix it in the language
“For example, I want the next C grammar to define that a space comes between any keyword and an opening parenthesis. "if (foo)" would be legal, but "if(foo)" would not. Not a warning, not optionally checked, but actually forbidden by the language parser. Flat out illegal. Can't compile.
... There is not now, nor will there ever be, a programming style whose benefit
is significantly greater than any of the common styles. Get real. Discovering a style that improves your productivity by more than a few percent over the common styles is about as likely as discovering a new position for sex.”
Ken Arnold, “Style is Substance”www.artima.com