Twitter icon.
Random notes on software, programming and languages.
By Adrian Kuhn

The 6th Rule of Variable Naming


Personally, I take particular care when naming methods. An often neglected detail is that an object’s public method names are almost ever written following the variable name holding an instance of the object. Thus, it is rather pointless to start all methods of a Factory class with the verb create, rather we can omit it and stick to the convention that its instances must be named create!

Factory create = new Factory();
Node n = create.Node();
Edge e = create.Edge();
…

In lack of a better name, I am calling this the Read-Aloud naming convention.

I have first stumbled upon this convention when reading the sources of the Java Compiler. Other occurrences known to me are restricted to the naming of static methods. For example Yossi Gil’s awesome Default class which returns a default value if a given variable is null.

String guess = Defaults.to(answer, "A");

Another example of Read-Aloud naming is the headline of this blog, which refers to the creation of examples in the JExample testing framework.

Stack stack = For.example(StackTest.class, "withManyValues");

PS—if you are looking for the first five rules of variable naming, please refer to Ian Hickman’s recently digged 5 Rules of Variable Naming.

3 Responses to “The 6th Rule of Variable Naming”

  1. Chris Says:

    I like your thinking. Readable, well commented code is always a great legacy to leave to your successor. Having said that, i’m willing to bet you’re a ruby coder by night…

  2. troelskn Says:

    Sounds like a variation of FluentInterface[1] to me.

    [1] http://www.martinfowler.com/bliki/FluentInterface.html

  3. kL Says:

    Looks much like Cocoa/Objective C naming, e.g. [NSArray withObjects:...]

For.example is Digg proof thanks to caching by WP Super Cache!