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

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 agree with @Johnny Wey; name your variables - for the same reason you name them in any other code! Don't understand this predalection away from clarity just because of the "in-line" nature of the code. Readability is key - at a glance/w/out having to "hover" over stuff; otherwise, you might as well say no variable needs to be named appropriately. Maybe a little leeway if used with something "Enuerable", but still nice to see (again at a glance) what the heck the code is doing. If variable type inference is relying on some generic type passed into the class or something, c'mon, name it. Make all code read like a sentence; the computers are supposed to be adapting to us ("humanizing"), not the other way around where we start acting like computers and getting cryptic just because we can/feel smarter/more like tech geeks when we do (temptation is there, I kno!). It's easy to type a clear name and you still have all the Intellisense/sentence completion options you do in named methods. Plus, hovering in the case of lambdas doesn't always give you info on the var (frustrating during debug), so it's nice to see "clear/representative enough" naming, esp for new devs who havent been thru all the mental gymnastics to be able to infer the types by traversing the statement context (which also can be cryptic).

Answer 2

Based on the answers above, I think there is general consensus that, if you can't tell from the context what you are dealing with, using a descriptive name is better. For example:

entities.Where(person => person.Age >= 21);

In cases where the context is obvious, however, a single-letter name may actually help readability, because it makes it easier to focus on the critical information. For example:

people.Where(p => p.Age >= 21); or people.Where(x => x.Age >= 21);

The question is, which is better, p or x?

• In favor of p, it's a familiar pattern in SQL queries and provides a little extra reminder that you are talking about a Person.
• In favor of x, if you rename Person to Customer, you don't have to worry about fixing all your lambda parameters. If you had used p, it would actually be a little confusing if your code became customers.Where(p => p.Age >= 21), whereas x is basically agnostic.

I've recent started using x, and so far, I haven't noticed any significant downside, but please comment if you disagree.

Answer 3

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 4

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 5

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 6

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.