Lambda variable names - to short name, or not to short name? [closed]

Answer 1

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 2

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 3

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 4

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.

Answer 5

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).