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

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?

From stackoverflow

• 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;
  

  TheSoftwareJedi : yes, I tend to name better in expression syntax, but that's because the scope is wider, and can become confusing.

  TheSoftwareJedi : In expression syntax, I usually name longer names as the scope is wider. I don't see the point of writing .OrderBy(theInt => theInt) instead of .OrderBy(a => a).

  Jon Skeet : It makes it clearer what the element is at that point of the query. It's not always obvious, unfortunately.

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

• 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
  

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

  TheSoftwareJedi : I see questioning the naming in expression syntax as different than the naming in lambda syntax.

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

  TheSoftwareJedi : +1 Thanks for the book

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

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

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