Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

[Note: The below is a bit C# heavy in its syntax and conventions, such as citing FxCop rules, because this is my background, but the intent of this discussion is to be language-agnostic and the code examples used should generally be regarded as pseudo-code. — Mike]

I think we would all agree that classes should generally be designed so that their object instances are immutable wherever practical, and the results of calling class members should be free of side effects, as much as possible.

Historical naming conventions, however, tend to use the active voice: 'GetSomething', 'DoSomehing', etc. and this is good because it states clearly what action that the class member is going to take.

I am now beginning to think, however, that members might sometimes (or possibly often) benefit by being named in the past tense to connote that a value is returned without affecting the referenced object.

For example, for a method that transposes an array, current naming styles would probably have it called 'Array.Transpose', but if this member returns a new array, without transposing the referenced object, then I think that calling it 'Array.Transposed' would be more accurate and makes it clearer to the programmer.

When working with an 'Array.Transpose()' method one might accidentally try to use code such as the following:

Array myArray = new Array(); 
myArray.Transpose();

But if the 'Transpose' method returns a new array without affecting the referenced object, then this code does nothing — that is, 'myArray' would quietly not be transposed. (I suppose that if 'Transpose' were a property, then the compiler would catch that the above is not legal, but FxCop guidelines state that a member that performs a conversion should be a method.)

But if the method were named in the past tense as 'Array.Transposed', it would be clearer to the user that the following syntax is required:

Array myArray = new Array(); 
Array transposedArray = myArray.Transposed();

Other names that I think would fit into this category would be members named 'Resized' vs. 'Resize', 'Shifted' vs. 'Shift', etc. The present tense would be used for members that affected the referenced object, while the past tense would be used for members that returned a new value without affecting the referenced object.

Another approach that is more common currently is to prefix each name with "Get" or "To", but I think that this adds unnecessary weight, while changing to past tense communicates the meaning effectively.

Does this make sense to other programmers here, or does this past tense idea sound too awkward when reading it?

Edit:

Great discussions below, I thank everyone a lot. A few points I'd like to summarize based on your comments and my own revised thinking on this follows below.

Method Chaining "Fluent" Syntaxes

Based on the discussions below, the use of the past tense is probably of some value when used on a mutable class in order to make it clear which members do, or do not, affect the internal state of the referenced object.

However, for immutable classes, which should be the majority of the cases (one would hope), I think that the use of the past tense can make the syntax unnecessarily awkward.

For example, with "fluent syntaxes" such as those created by method chaining, the use of past tense would make the code less readable. E.g., when using LINQ via C#, a typical method chain could look as follows:

dataSource.Sort().Take(10).Select(x => x.ToString);

If changed to the past tense, this would become awkward:

dataSource.Sorted().Taken(10).Selected(x => x.ToString);

Mind you, dataSource.Sorted() is actually clearer in meaning than dataSource.Sort(), because LINQ expressions always create a new enumeration without affecting the source. However, since we are fully aware of this when using this paradigm, the use of past tense is redundant and makes the "fluency" of reading it awkward for no real gain.

Use of Properties vs. Methods

A key issue that was brought up below regards the FxCop guidelines for the use of "Get" methods vs. read-only properties. E.g., FxCop rule CA1024.

Although not explicitly mentioned in that FxCop rule, the use of "To" methods would seem to apply to this rationale as well, since ToXXXXXX() methods are conversion methods. And in the case of ToArray(), the method is both a conversion method and is a method that returns an array.

Use of Past Tense for Boolean Properties

Some suggested that the past tense can connote a boolean value, e.g. a 'Succeeded' or 'Connected' property. I believe that the retorts below emphasizing the use of an 'Is', 'Has', or 'Are' for Boolean properties and fields are correct. Past tense can help in this regard too, but not nearly as much as using an 'Is' prefix. Feel free to use the past tense for Boolean properties and fields, it does help, but I think that it's even more important to prefix the name with 'Is', 'Has', or 'Are'.

Overall Conclusions?

For the issue of Tranpose() vs. Transposed(), I think that 'skizzy' got it right, suggesting that it should be Transpose() for a mutating action vs. GetTransposed() for a non-mutating result. This makes it 100% clear. But, again, I think that this might only apply for a mutuable class, such as an array.

For immutable classes, especially where a fluent method-chaining syntax might be used, then I think that this syntax would become unnecessarily awkward. For example, compare:

var v = myObject.Transpose().Resize(3,5).Shift(2);

to:

var v = myObject.GetTransposed().GetResized(3,5).GetShifted(2);

Hmmm... actually, even here it seems to make it 100% clear that the result does not affect the source, but I'm not sure.

I guess for a paradigm like LINQ where it is well known, the use of "Get" and/or the past tense is not necessary, but for a new API, it might have some value -- at first! If the API contains only immutable objects, once the user understands this, the use of "Get" and/or the past tense only reduces the readability.

So I think there are no easy answers here. I guess one needs to think about the entirety of your API and choose carefully!

-- Mike

share|improve this question
    
I sure hope you just forget the parens for method invocation (or those are optional in the language the examples are in, although that's rare) and you didn't intend these to be properties... –  delnan Apr 22 '11 at 21:05
    
Hi delnan, yes, it's a property and it's intensional. By being a property it's even clearer that the 'Transpose' (or 'Transposed') property returns a value and shouldn't have a side-effect. In fact, the compiler should pick up the incorrect code usage above, but the idea here is to try to be even clearer to the user -- before the compiler picks it up. –  Mike Rosenblum Apr 22 '11 at 21:10
    
I think it's a very bad idea to use properties for everything as creating a wholly new object. And to back it up, MSDN says a method is preferrable to a property if "The method performs a time-consuming operation. The method is perceivably slower than the time it takes to set or get a field's value." –  delnan Apr 22 '11 at 21:32
    
Nice source, thanks a lot for that. So my 'Transposed' example might have have been ideal, as it trips over FxCop rule CA1024 because this member (a) performs a conversion and (b) returns an array. That said, the discussion regarding present vs. past tense still applies, but I'll definitely use ToXXXXX() or GetXXXX() methods instead of properties when returning a conversion or array result! –  Mike Rosenblum Apr 22 '11 at 21:54
    
I think you mean objects should be immutable, not classes. Classes are generally always immutable, at least in statically typed languages. –  Nemanja Trifunovic Apr 22 '11 at 22:26

7 Answers 7

Past-tense kinda sounds awkward. I think that you intended the word to be an adjective.

Here's my suggestion to the problem you asked for: instead of Transpose(), call it GetTransposed(). That way, you know that you are receiving something and not modifying the object.

share|improve this answer
1  
I think that, in the end, that this is actually the "right" answer. I'm not going to mark it as "correct" because (1) some others, particularly 'qes' and 'Developer Art' made some really thoughtful comments, and (2) I don't really think that there's a "right" answer to this -- this is more of a "Community Wiki" question. (Does p.se have such a concept?) –  Mike Rosenblum Apr 22 '11 at 23:08
1  
+1 Nice concise answer! This way Transpose() can still be interpreted as adjusting the given object. Perhaps this should be a language construct. :) object.Transpose() vs object:Transpose(). –  Steven Jeuris Apr 22 '11 at 23:22
    
I prefer AsTransposed rather than GetTransposed for cases where consecutive repeated calls will, without side-effects, yield semantically-identical results (which may or may not be the same object, but could not be shown to be different objects without using things like ReferenceEquals or the equivalent). –  supercat Jul 11 '12 at 6:59

In the Scala collections library, there are a few methods that are in the past tense:

  • grouped returns an iterator which iterates over the elements of a sequence in chunks of n elements
  • sorted returns a sorted version of the collection
  • updated returns a new version of the collection with one element changed

However, I'm not sure whether this was a conscious decision or whether they simply ran out of names, because Scala's collection library is very rich. For example, there are also groupBy and sortBy methods, and the update method is special, because the compiler rewrites assignment

foo(bar) = baz

into

foo.update(bar, baz)

Older versions of Scala indeed did use update for immutable collections, but having update return a new version instead of mutating is very awkward, because you obviously have to assign the return value to something, so e.g. "updating" an entry in an immutable map would be something like

val newMap = oldMap(key) = value // HUH ??!!??

Now, it is

val newMap = oldMap.updated(key -> value)

In a language with a good type system, the types will usually tell you whether or not the routine mutates its arguments. In Haskell, for example, the type of the immutable version would be something like

transpose :: Array -> Array

whereas a mutable version would be like

transpose :: State Array
share|improve this answer
    
Wow, great discussion and examples. Thanks! –  Mike Rosenblum Apr 22 '11 at 23:10

When I see a method/property in the passed tense I immediately assume it returns a boolean. Your proposal may make sense logically, but it just seems strange and awkward. If I have to explain to someone why it makes sense it is probably not a good convention.

share|improve this answer
2  
That's why it's a good convention to prefix boolean values with "is". ;p Furthermore, the reason he explains it is because it isn't a convention. Some answers to this question rely too much on existing conventions. You need to be able to step aside and judge it without a known convention. –  Steven Jeuris Apr 22 '11 at 22:50

I'm not a big fan of past-tense variable names for immutability - it's a somewhat unusual convention and I think it would cause confusion, especially for those individuals who are not particularly strong at English grammar (and I'm only half-joking there...)

Also, this conventions removes the opportunity of using past tense to denote something else which I think is more important: a description of the state of the described object, e.g. "processed-items" clearly tells you that the items in a collection have already been processed, which is important logical information to convey.

A better idea: make everything immutable. Then you don't need any fancy linguistic distinction. You know you want to :-)

share|improve this answer
1  
That's why it's a good convention to prefix boolean values with "is" and "has". –  Steven Jeuris Apr 22 '11 at 22:57

I strongly disagree. Past-tense is awkward and is not commonly used (which is reason enough in itself not to prefer it).

If the method modified the object it was called on, it shouldn't return itself - this makes it clear that it modifies the object.

Likewise, if the method doesn't modify the object it was called on and instead constructs a new object, the method will return an object of the same type. This is a clear and already common convention.

The method signature is, in my opinion, a clearer and much more commonly used convention to indicate if the method returns a new object or modifies the callee.

share|improve this answer
    
Hi qus, yes, the past tense approach is not commonly used, which is why I posed the question here. (I think it makes sense, but precedent does count for a lot.) Your point about the method signature is a good one, but, unfortunately, is an extremely subtle one because compilers generally do not enforce that the result of a method be used. So a compiler could not catch the mistake of calling myObject.Resize() and not making use of the return value. My proposal is that naming the method "Resized" would make it clearer to the programmer that result = myObject.Resized() is required. –  Mike Rosenblum Apr 22 '11 at 22:02
1  
Compilers can certainly warn that the result of a method is not used, which is more than they can do for any behavior based on the tense of a verb in the English language used in an identifier, so that's an invalid point. I am stating that naming in the past tense will not make it clearer because: 1. It is not an established convention. 2. There are other more established conventions 3. There will be many words that will be exceptionally awkward or entirely invalid to have in a past tense, whereas method signatures will not suffer that confusion. –  qes Apr 22 '11 at 22:10
    
Sure compilers could warn for this, but they generally only do so for properties. Return values from methods that are not used are generally ignored by almost all compilers on standard settings. –  Mike Rosenblum Apr 22 '11 at 23:02
    
That said, the more I think about your comments and FxCop rule CA1024 (msdn.microsoft.com/en-us/library/ms182181(VS.80).aspx), my examples are all situations where a conversion is occurring and/or where an array is being returned. The result is that these should use a GetXXXXX() or ToXXXXX() method naming, and I think that this is right. (Especially since it is the established convention.) I do think that naming the method in the passed tense, as in "GetTransposed()", is still helpful here, but only marginally. –  Mike Rosenblum Apr 22 '11 at 23:22

It does make sense indeed.

What you are talking about, in my opinion, should be taken as a general rule when designing an API or a library. Only then would it offer a tangible benefit if the system is consistent throughout all of the classes.

Another issue is that in many cases users of the interfaces don't quite care about how the result is achieved.

Will Transpose() transpose the current object? Will Transpose() create a new transposed instance and return the reference to it? Or will it perhaps transpose once, cache the results in a copy and return it at subsequent calls without affecting the current object?

Users often just want to get the transposed result, which is why not many will care about the naming convention you're proposing.

But on its own right, it is a valid proposal.

share|improve this answer

Sounds reasonable, and there are precedents — Python has both list.sort() and sorted(seq). The first is a method, the other one is a function that acts on any iterable and returns a list.

share|improve this answer
    
does list.sort() return anything? –  qes Apr 22 '11 at 21:50
    
No, it doesn't. –  Adam Byrtek Apr 22 '11 at 21:54

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.