Lambda变量名称 - 短名称,还是不短名称?

时间:2009-01-14 15:55:26

标签: c# .net naming-conventions lambda

通常,当我使用lambdas时,我只使用“a,b,c,d ......”作为变量名称,因为类型很容易推断,我发现短名称更容易阅读。这是一个例子:

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

有些人质疑这个命名,并且更愿意看到长输出的名称,如下所示:

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

由于范围很窄(在parens之间),除非你变得愚蠢并将它们嵌套,否则我会发现阅读短名称更容易。

没有被我上面使用的愚蠢命名示例所吸引,对Lambda变量名称的一般共识是什么?要简短的名字,还是不要简短的名字?

11 个答案:

答案 0 :(得分:36)

我通常这样做的方式取决于你所列举的集合。如果集合的名称暗示lambda参数将是什么类型,那么我只使用单个字母,但是如果集合不是描述性的,那么我将使用一个单词。

IE:

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

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

答案 1 :(得分:14)

我尝试使用单字但有意义的名字。所以我倾向使用“person”而不是“p”,但不会选择“newlyAddedPerson”。

这也适用于查询表达式 - 我可能会在快速一次性的例子中违反这一点,但我一般不喜欢:

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

我宁愿看到

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

答案 2 :(得分:5)

我喜欢这个简称。我一直这样做。我主要在lambdas中使用i,y,x,但我在sql中使用a,b,c,d。

答案 3 :(得分:3)

我说我同意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'代表'数字'。我认为“数字”也可以,但对我的口味来说有点过于冗长。

我当然不会使用名称'nameOfPerson'或'previousOddNumber'。这只是太多的信息。我也会尝试在大多数情况下保留我的姓名,例如'nameString'。在大多数情况下,我发现这样的东西是多余的信息。

就个人而言,我认为这类额外的冗长名称往往源于它有助于记录代码的想法。它似乎在Java / C#等语言中尤为普遍。我认为这可以通过两种方式进行争论,具体取决于程序员的风格。但是,名称越详细,代码就越紧(读得脆弱)。如果我的名字非常具体,并且它的功能经常发生变化,那么名称也可能会发生很大的变化。最终,DEV可能会变得懒惰,并且您最终会得到一个名称,该名称实际上并未描述变量的用途。当且仅当程序员不认为名称正确时,这不是问题。当然,这可能会在编译过程中快速计算出来(因为程序员会尝试划分两个字符串或某些东西),但这会导致大型项目浪费时间和混乱。

我还会因为屏幕不动产而争论简洁。我仍然试图将我的行包裹在80列宽,当'myVaraibleNameIsAsLongAsAParagraph'时这很难。

最终,我认为它总是会妥协。所以他们不喜欢'a',但也许他们可以同意你应该争取像'人'或'数字'这样的单词名称,并避免那种糟糕的骆驼案例。

抱歉这本书。

答案 4 :(得分:3)

我们的团队不允许使用单字母变量,而不允许使用lamdas中的事件。

我们发现,就像在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),需要将它分解成更小的块。

答案 5 :(得分:2)

可能要求很多人就“命名”提出“共识”问题。 :)

我同意'好名字的重要性'与名称的范围成正比。 Jon Skeet的回答是

from person in source ...

很有吸引力,但是如果名字被大量使用,特别是如果输入名称更好,我想我更喜欢

from p in persons ...

答案 6 :(得分:1)

我使用一个,两个或三个字母,这些字母形成了相关对象的缩写表示。

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

答案 7 :(得分:1)

作为一般规则,我认为变量/对象/方法名称越明确越好。由于我们经常花大部分时间阅读其他人的代码,因此我们更容易理解,您可以更快地将注意力集中在语法和逻辑上。这些天使用IntelliSense等,尽可能在清晰度方面犯错并不是真正的负担。

答案 8 :(得分:0)

我同意@Johnny Wey;命名您的变量 - 出于同样的原因,您可以在任何其他代码中命名它们!仅仅因为代码的“内联”性质,不能理解这种远离清晰度的偏好。可读性是关键 - 一目了然/不需要“悬停”过东西;否则,你可能会说没有变量需要适当命名。如果使用“Enuerable”这个东西可能有点余地,但仍然很高兴看到(再次一目了然)代码正在做什么。如果变量类型推断依赖于传递给类或类似物的某些泛型类型,请来命名。将所有代码读成句子;计算机应该适应我们(“人性化”),而不是相反,我们开始像计算机一样行动并且变得神秘,因为我们可以/感觉更聪明/更像技术极客当我们这样做(诱惑在那里,我硝酸钾!)。输入一个清晰的名称很容易,你仍然拥有在命名方法中所做的所有Intellisense /句子完成选项。另外,在lambdas的情况下徘徊并不总是给你关于var的信息(在调试期间令人沮丧),所以很高兴看到“清楚/有代表性”的命名,尤其是那些没有通过所有心理体操的新开发者能够通过遍历语句上下文来推断类型(也可能是神秘的)。

答案 9 :(得分:0)

如果变量的目的明确,缩短更好。 Lambdas需要一种功能性的写作风格,因此你会在一行中看到很多链接。当你把它们缩短时,它看起来更干净。

另一种情况是,有时您需要声明一个在该范围内没有相关性/含义的虚拟变量。在这种情况下,我使用_,这对我来说很清楚。这在方法重载期间尤其方便,例如,

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

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

答案 10 :(得分:0)

基于上面的答案,我认为普遍的共识是,如果你无法从上下文中判断出你在处理什么,使用描述性名称会更好。例如:

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

在上下文 明显的情况下,单个字母的名称实际上可能有助于提高可读性,因为它可以更容易地关注关键信息。例如:

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

问题是,哪个更好,px

  • 赞成p,这是SQL查询中熟悉的模式,并提供一些额外提醒,说明您正在讨论Person
  • 支持x,如果您将Person重命名为Customer,则无需担心修复所有lambda参数。如果您使用过p,如果您的代码变为customers.Where(p => p.Age >= 21),那么实际上会有点混乱,而x基本上是不可知的。

我最近开始使用x,到目前为止,我没有注意到任何明显的缺点,但如果您不同意,请发表评论。