我通常做法取决于你枚举的集合。如果集合的名称暗示了 lambda 参数的类型，那么我就使用单个字母，但如果集合不够描述性，那么我会使用单词。

IE: 互联网浏览器

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

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

我尝试使用有意义的单词命名。所以我倾向于使用“人”而不是“p”，但不会选择“newlyAddedPerson”。

这同样适用于查询表达式 - 我可能会在快速的临时示例中违反这一点，但我通常不喜欢：

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

我宁愿看到

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

我们的团队不允许使用单个字母的变量，即使在 Lambda 中也不行。

我们发现的是，就像在TSQL中一样，代码存活的时间越长，它就变得越混乱。就lambda而言，

我们会做类似这样的事情：

people.Where(personFound => personFound.FirstName.Contains("blah!"));

这样下一个开发者就不必看了。

people.Where(p => p.FirstName.Contains("blah"));

它看起来可读，但一开始总是这样。

加入是怎么样的？

citizenShip.Join(people, c => c.personid, p => p.persoinid, (p, c) => new { p.FirstName, c.IsCitizen})
.Where(pc => pc.FirstName.Contains("blah");

与变量名称相同

citizenShip.Join(people, 
                 citizenToJoin => citizenToJoin.personid, 
                 personToJoin => personToJoin.persoinid, 
                 (joinedPerson, joinedCitiznship) => 
                     new { joinedPerson.FirstName, joinedCitiznship.IsCitizen})
.Where(personAndCitizenshipFound=> personAndCitizenshipFound.FirstName.Contains("blah");

哦，但这很混乱和丑陋。只需使用不同的字母，这样就不那么令人困惑了。

citizenShip.Join(people, 
                 c => c.personid, 
                 p => p.persoinid, 
                 (jp, pc) => 
                     new { jp.FirstName, jc.IsCitizen})
.Where(pc => pc.FirstName.Contains("blah");

仍然很困惑，但现在更糟了。因此，我们要分解lambda，以便进行重构，以提高可读性。

var peopleWithCitizenship = citizenShip.Join(people, 
                                             citizenToJoin => citizenToJoin.personid, 
                                             personToJoin => personToJoin.persoinid, 
                                             (joinedPerson, joinedCitiznship) => new { joinedPerson.FirstName, joinedCitiznship.IsCitizen});

var peopleWithCitizenshipFilteredByName = peopleWithCitizenship.Where(personAndCitizenshipFound=> personAndCitizenshipFound.FirstName.Contains("blah"));

这不是一个完美的例子，但可以用很少的内部知识使代码易读。我们发现这暴露了复杂的代码（lambda），需要将其分解为更小的块。

我喜欢简短的名称。我总是这样做。我在Lambda中主要使用i，y，x，但在SQL中我使用a，b，c，d。

我想我同意BFree的观点。对我来说，这取决于上下文，但我总是尽可能地简明扼要。请注意我说的是简明，而不是简短或简洁。

这里有两个LISP方言Clojure的例子：

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

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

对于那些不了解Lisp/Clojure的人来说，我的lambda是函数filter的参数。也就是说，"(fn [name] ....)"。我选择在这里使用name，因为它很短，但可以准确描述我的工作。然而，我认为a、i、x等名称同样易读。

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

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

这里，我只是用 n 代替数字。我认为“数字”也可以，但对我来说稍微有点冗长。

我绝对不会使用“人名”或“前奇数”的名字。这已经是太多的信息了。大部分时间我也会尽量避免在变量名中加入数据类型，例如“名字字符串”。我认为这样的东西往往只是多余的信息。

个人而言，我认为像这样过于啰嗦的名称往往源自于帮助记录代码的想法。在像Java/C#这样的语言中，这种情况似乎尤为普遍。我认为这可以根据程序员的风格进行讨论。然而，名称越啰嗦，代码就越紧密（易碎）。如果我的名字非常具体，而且功能经常更改，那么名字也很可能会经常改变。最终，开发人员可能会变得懒惰，你将会得到一个实际上描述不了变量用途的名称。这不是一个问题，前提是程序员不假定名称是正确的。当编译时，这可能很快被发现（因为程序员会尝试将两个字符串分开或者进行其他类似的操作），但它可能会在更大的项目中造成浪费的时间和混乱。

我也会主张言简意赅，因为屏幕实际空间有限。我仍然尝试将我的行限制在80个字符宽度内，但当我的变量名像段落一样长时，这是很困难的。

最终，我认为这总是要妥协的。所以他们不喜欢 a，但也许他们可以同意你应该努力使用像 "person" 或 "number" 这样的单词名称，避免那种糟糕的驼峰式命名。

对不起，这本书。

这可能要求太多了，要求达成命名的共识。 :)

我同意，一个好的名字的重要性与名字的范围成正比。乔恩·斯基特（Jon Skeet）更喜欢...（未提供细节）

from person in source ...

这很有说服力，但如果这个名字被广泛使用，特别是如果有更好的输入名称，我认为我更喜欢。

from p in persons ...

我使用一个、两个或三个字母，组成缩写来代表所涉及的对象。

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

基于上述答案，我认为普遍的共识是，如果你无法从上下文中确定你正在处理什么，使用描述性的名称会更好。例如：

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

然而，在上下文明显的情况下，一个单字名称实际上可能有助于阅读，因为它使人更容易聚焦于关键信息。例如：

people.Where(p => p.Age >= 21); 或 people.Where(x => x.Age >= 21); 人们。其中(p = > p.年龄> = 21); 或人们。其中(x = > x.年龄> = 21);

这个问题是哪个更好，p还是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.

我最近开始使用x，到目前为止，我还没有发现任何明显的不利方面，但如果您不同意，请评论。

通常，我认为变量/对象/方法名称越明确越好。由于我们经常花费大部分时间阅读他人代码，理解得越容易，您就可以更快地将注意力从语法转移到逻辑上。现在有了IntelliSense等工具，尽可能清晰明了并不会造成负担。

我同意@Johnny Wey的观点；变量的命名跟其他代码一样重要!不要因为代码的“内联”性而把模糊的偏好放在第一位。阅读性很关键——一眼看过去不用“悬停”；不然你也可以说没有一个变量需要被适当命名。也许用于某些“可枚举”事物时可以稍作宽松，但用来看到（再一次，是一眼）代码正在做什么还是不错的。如果变量类型推断依赖于传递给类的某个泛型类型之类的东西，就给它起个名字吧。让所有代码像一句话一样阅读；计算机应该正在适应我们（“人性化”），而不是反过来我们开始像计算机一样编程，变得神秘起来只因为我们可以/觉得更像技术极客（尽管这是很有诱惑力的，我知道！）。起一个清晰的名字很容易，但你仍然可以使用所有的Intellisense/语句完成选项，就像在具名方法中一样。此外，在lambda表达式中，悬停并不总是能够给出变量信息（在调试时很烦人），所以看到“足够清晰/代表性”的命名还是很不错的，尤其是对于没有通过思维摔跤来推断类型的新开发人员（这也可能会让人感到神秘）。

如果变量的目的明确，缩短变量名称更好。Lambda 调用函数式编写风格，因此您会看到大量的链接在一行中。如果您保持它们短小，就会更干净清晰。

另一个情况是有时您需要声明一个虚拟变量，它在该范围内没有相关性/含义。在这种情况下，我使用_，这对我来说很清楚。在方法重载中特别有用。

public Foo Do()
{
    return Do(_ => true);
}

public Foo Do(Func<T, bool> pattern)
{
    return SomethingElse(pattern);
}