Lambda variable names - to short name, or not to short name?

Question

Typically, when I use lambdas, I just use "a, b, c, d..." as variable names as the types are easily inferred, and I find short names to be easier to read. Here is an example:

var someEnumerable = GetSomeEnumerable();
var somethingElseList = someEnumerable.Select(a => a.SomeProperty)
                                      .OrderBy(a => a.SomePropertyField);
var someDictionary = somethingElseList.ToDictionary(a => new SomeClass(a.Prop1),
                                                    a => a);

Some question this naming, and would prefer to see long typed out names, like this:

var someEnumerable = GetSomeEnumerable();
var somethingElseList = someEnumerable.Select(importantObj => importantObj.SomeProperty)
                                      .OrderBy(objsInfo => objsInfo.SomePropertyField);
var someDictionary = somethingElseList.ToDictionary(theInfoId => new SomeClass(theInfoId.Prop1),
                                                    theInfoId2 => theInfoId2);

Since the scope is so narrow (between the parens), unless you're getting stupid and nesting them, I find it easier to read short names.

Without getting caught up in the silly naming examples I used above, what is the general consensus on Lambda variable names? To short name, or not to short name?

Answer 1

I try to use single-word but meaningful names. So I would tend to use "person" rather than "p" but wouldn't go for "newlyAddedPerson".

This goes for query expressions as well - I may well violate this in quick throwaway examples, but I don't generally like:

from p in source
where p.Age > 10
select p.Name;

I'd far rather see

from person in source
where person.Age > 10
select person.Name;

Answer 2

I like the shortname thing. I do that all the time. I mostly use i,y,x in lambdas, but I use a,b,c,d in sql.

Answer 3

The way I usualy do it depends on the collection you're enumerating over. If the name of the collection implies what type the lambda parameter will be, then I just go with the single letter, however if the collection isn't as descriptive, then I'll use a word.

IE:

myCollection.Where(person =>....); //non descriptive collection name

myPeopleCollection.Where(p=>...); // descriptive collection name

Answer 4

It may be asking a lot to ask a question for 'consensus' on 'naming'. :)

I agree that 'the importance of a good name' is proportional to the scope of the name. Jon Skeet's answer of preferring

from person in source ...

is compelling, but if the name is used a lot and especially if the input is better named, I think I prefer

from p in persons ...

Answer 5

I'd say I agree with BFree. That, for me, it will depend on the context, but I always try to make it as 'concise' as possible. Notice I say concise, and not terse or short.

Here's two examples in the LISP dialect Clojure:

user=> (def names ["ryan" "bob" "tom" "tim"])
#'user/names

user=> (filter (fn [name] (.startsWith name "t")) names)
("tom" "tim")

For those that don't know Lisp/Clojure, my lambda is the argument to the function 'filter'. That is, "(fn [name] ....)". I chose to use 'name' here because it's short but describes exactly what I'm working with. However, I think an 'a', 'i', 'x', etc would be just as readable.

user=> (def odds (iterate (fn [n] (+ n 2)) 1))
#'user/odds

user=> (take 5 odds)
(1 3 5 7 9)

Here, I just use 'n' to stand for 'number'. I think 'number' would be OK too, but is slightly too verbose for my taste.

I certainly would NOT use the names 'nameOfPerson' or 'previousOddNumber'. That's just WAY too much information. I also try to keep types out of my names most of the time, e.g. 'nameString'. I find stuff like that, most of the time, to be superfluous information.

Personally, I think extra verbose names like that tend to stem from the idea that it helps document the code. It is especially prevalent in languages like Java/C# it seems. I think this could be argued both ways, depending on the programmer's style. However, the more verbose the name, the more tight (read brittle) the code can become. If my name is very specific, and it's a function changes often, then chances are the name will have to change a lot too. Eventually, the DEV might get lazy and you'll end up with a name that doesn't actually describe what the variable is used for. This is not a problem, if and only if the programmer doesn't assume the name is correct. Granted, this would probably be figured out quickly during compilation (because the programmer will try to divide two strings or some such thing), but it can cause wasted time and confusion in larger projects.

I would also argue for conciseness because of screen real-estate. I still try to wrap my rows at 80 columns wide, and that's hard when 'myVaraibleNameIsAsLongAsAParagraph'.

Ultimately, I think it's always going to come down to compromise. So they don't like 'a', but maybe they can agree that you should strive for one-word names like 'person' or 'number', and avoid that awful camel case.

Sorry for the book.

Answer 6

I go with one, two or three letters, which form an abbreviated representation of the object in question.

Persons.Where(p => ...)
AnalysisCode.Where(ac => ...)

Answer 7

As a general rule, I think the more explicit you are with variable/object/method names the better. Since we often spend most of our time reading other people's code, the easier it us to understand the faster you can get your focus off the syntax and onto the logic. These days with IntelliSense and the like, it's not really a burden to err on the side of clarity whenever possible.