Do you use articles in your variable names?

Question

Edit: There appears to be at least two valid reasons why Smalltalkers do this (readability during message chaining and scoping issues) but perhaps the question can remain open longer to address general usage.

Original: For reasons I've long forgotten, I never use articles in my variable names. For instance:

aPerson, theCar, anObject

I guess I feel like articles dirty up the names with meaningless information. When I'd see a coworker's code using this convention, my blood pressure would tick up oh-so-slightly.

Recently I've started learning Smalltalk, mostly because I want to learn the language that Martin Fowler, Kent Beck, and so many other greats grew up on and loved.

I noticed, however, that Smalltalkers appear to widely use indefinite articles (a, an) in their variable names. A good example would be in the following Setter method:

name: aName address: anAddress.
     self name: aName.
     self address: anAddress

This has caused me to reconsider my position. If a community as greatly respected and influential as Smalltalkers has widely adopted articles in variable naming, maybe there's a good reason for it.

Do you use it? Why or why not?

Answer 1

I always felt the articles dirtied up the names with meaningless information.

Exactly. And this is all the reason necessary to drop articles: they clutter the code needlessly and provide no extra information.

I don’t know Smalltalk and can't talk about the reasons for “their” conventions but everywhere else, the above holds. There might be a simple technical reason behind the Smalltalk convention (such as ALL_CAPS in Ruby, which is a constant not only by convention but because of the language semantics).

Answer 2

Never used, maybe because in my main language there are not any articles :P

Anyway i think that as long as variable's name is meaningful it's not important if there are articles or not, it's up to the coder's own preference.

Answer 3

It is in common use in Smalltalk as a typeless language because it hints the type of an argument in method call. The article itself signals that you are dealing with an instance of some object of specified class.

But remember that in Smalltalk the methods look differently, we use so called keyword messages and it this case the articles actually help the readability:

anAddressBook add: aPerson fromTownNamed: aString

Answer 4

Nope. I feel it is waste of characters space and erodes the readability of your code. I might use variations of the noun, for example Person vs People depending on the context. For example

ArrayList People = new ArrayList();
Person newPerson = new Person();
People.add(newPerson);

Answer 5

No I do not. I don't feel like it adds anything to the readability or maintainability of my code base and it does not distinguish the variable for me in any way.

The other downside is if you encourage articles in variable names, it's just a matter of time before someone does this in your code base.

var person = new Person();
var aPerson = GetSomeOtherPerson();

Answer 6

I think I just found an answer. As Konrad Rudolph said, they use this convention because of a technical reason:

...this means it [method variable] cannot duplicate the name of an instance variable, a temporary variable defined in the interface, or another temporary variable. -IBM Smalltalk Tutorial

Basically a local method variable cannot be named the same as an object/class variable. Coming from Java, I assumed a method's variables would be locally scoped, and you'd access the instance variables using something like:

self address

I still need to learn more about the method/local scoping in Smalltalk, but it appears they have no other choice; they must use a different variable name than the instance one, so anAddress is probably the simplest approach. Using just address results in:

Name is already defined ->address

if you have an instance variable address defined already...

Answer 7

Where I work, the standard is to prefix all instance fields with "the-", local variables with "my-" and method parameters with "a-". I believe this came about because many developers were using text editors like vi instead of IDE's that can display different colors per scope.

In Java, I'd have to say I prefer it over writing setters where you dereference this.

Compare

public void setName(String name) {
    this.name = name;
}

versus

public void setName(String aName) {
    theName = aName;
}

The most important thing is to have a standard and for everyone to adhere to it.

Answer 8

I wobble back and forth on using this. I think that it depends on the ratio of C++ to Objective C in my projects at any given time. As for the basis and reasoning, Smalltalk popularized the notion of objects being "things". I think that it was Yourdon and Coad that strongly pushed describing classes in the first person. In Python it would be something like the following snippet. I really wish that I could remember enough SmallTalk to put together a "proper" example.

class Rectangle:
    """I am a rectangle. In other words, I am a polygon
    of four sides and 90 degree vertices."""
    def __init__(self, aPoint, anotherPoint):
        """Call me to create a new rectangle with the opposite
        vertices defined by aPoint and anotherPoint."""
        self.myFirstCorner = aPoint
        self.myOtherCorner = anotherPoint

Overall, it is a conversational approach to program readability. Using articles in variable names was just one portion of the entire idiom. There was also an idiom surrounding the naming of parameters and message selectors IIRC. Something like:

aRect <- [Rectangle createFromPoint: startPoint 
                    toPoint: otherPoint]

It was just another passing fad that still pops up every so often. Lately I have been noticing that member names like myHostName are popping up in C++ code as an alternative to m_hostName. I'm becoming more enamored with this usage which I think hearkens back to SmallTalk's idioms a little.

Answer 9

This naming convention is one of the patterns in Kent Beck's book Smalltalk Best Practice Patterns. IMHO this book is a must-have even for non-smalltalkers, as it really helps naming things and writing self-documenting code. Plus it's probably one of the few pattern langages to exhibit Alexander's quality without a name.

Another good book on code patterns is Smalltalk with Style, which is available as a free PDF.

Generally, the convention is that instance variables and accessors use the bare noun, and parameters use the indefinite article plus either a role or a type, or a combination. Temporary variables can use bare nouns because they rarely duplicate the instance variable; alternatively, it's quite frequent to name them with more precision than just an indefinite article, in order to indicate their role in the control flow: eachFoo, nextFoo, randomChild...