Recently I've been looking at some of the VCL and VCL Form Designer code having to do with themeing where I've encountered variable names like UnthemedDesigner. As a result I find code like this:
if not UnthemedDesigner then
begin
FHasManifest := True;
Result := FHasManifest;
end
else
begin
// Do something else...
end;
When variable names are carefully chosen it sure can make everyone's life a lot easier. But then I wouldn't have anything to blog about. So here is a quick list off the top of my head when naming something.
Singular noun consisting of a class, interface, record, variable, field, accessor method, exception. For example: TControl, TButton.
Plural noun consisting of a variable or field holding a collection. For example: Items, Classes.
Verbs consisting of methods. For example: Dispose, GetItems, Delete.
Adjectives consisting of interface and boolean. For example: IDisposable, cloneable, IsEnabled.
Names should not be negative. "Un", "Not", etc should be avoided for clarity.
I'm sure you've seen similar lists before. If you haven't then you should go buy and read the book Design Patterns: Elements of Reusable Object-Oriented Software.
6 comments:
I think, "IsEnabled" should be, if the property is read-only. But if the property is writeable, it must be "Enable".
This is the kind of careful thinking I'm talking about. "IsEnabled" should be a read-only property. "Enable" should be a method because it is a verb. A read-write property would be "Enabled".
Which of your four rules explains why UnthemedDesigner is a bad variable name? Isn't the problem with your example really that the conditional statement is using the "not" operator on a variable that's already in the negative?
I think in your first rule you meant to say that a variable should not have the same name as a type, not that a variable name shouldn't be a singular noun. Nouns are great for variable names. Whether the noun is singular or plural has nothing to do with it -- type names can be both, and so can variable names.
I think your second rule might have meant to say that you shouldn't give a variable a name that's already taken by a property. Otherwise, what's wrong with Items or Classes as variable names? They look great to me.
In your third rule, why do you mention methods specifically? Overall, verbs make bad variable names whether they overlap with method names or not. The exception is for variables of function- and method-pointer types. Then verbs are great.
I'm completely puzzled by your fourth rule. Interface names, whether adjectives or not, are already covered by the first rule. An adjective like cloneable doesn't seem too bad. I see no problem with naming a variable IsEnabled. It's a perfectly valid predicate (but not an adjective).
Rob,
The examples I gave are examples of names to use. The confusion must be in the title of the post which I just changed.
Chris: you've still not fully answered Rob's question... How would using your rules invalidate that "UnThemedDesigner" variable/property name? And what would be a name for that using those rules?
Of course, just looking at a "not UnSomething" makes us think again about the name, but none of those rules applies to the example given...
Fernando,
Names should not be negative. "Un", "Not", etc should be avoided for clarity. I just added that rule.
Post a Comment