dev*_*xer 21 c# linq naming naming-conventions
我一直认为明确命名我的集合变量是"最佳实践".所以,如果我有一个Car对象的集合,我通常会命名为a Car[] carArray和a List<Car> carList.
然后99%的时间,我最终做了类似...
foreach (Car car in carArray)
{
...
}
......而且我在想,我本来可以调用数组cars,但它不会产生任何影响.
现在我们有了IEnumberable<T>,我实际上面临的问题是我是否可以考虑写一些类似的东西carIEnumerable？或carEnumerable.到目前为止,答案一直是"不".
我在这里的想法是,集合的类型通常无关紧要,如果将集合类型写入变量名称仍然无关紧要.我只是遇到了一个必须从IEnumerable<Car>a 切换到a的情况,List<Car>因为我需要对项目进行"括号访问"(例如carList[3]).在这种情况下,两种集合类型的行为不一样,但是命名变量cars在这里是一个问题吗？
不要在这个问题上添加另一层复杂性,如果我使用会发生什么var？例如,
var cars = GetCars();
我当然可以说cars是某种收藏品.我可以迭代它.如果我使用LINQ,我可以使用扩展方法.更重要的是,如果我后来更改了集合的类型,那么代码就会少得多.var仍然会var,cars现在仍然如此cars.这似乎对我很有吸引力,而且我很难看到很多劣势.
所以,只是为了确保我的问题清楚:你如何命名你的收集变量以及为什么？仅仅"复制"项目名称是否存在严重的可读性或清晰度成本？
Dan*_*ott 36
var car = cars.Where(c => c.Name == "Robin Reliant");
可读性获胜.
因此我选择多元化.
善良,
担
Bot*_*000 20
这种命名的问题在于它过分关注实际的实现而不是属性的目的.而不是CarArray,你可以使用OwnedCars,或任何告诉用户为什么存在枚举.
我认为在一个小循环中命名循环变量"car" foreach就好了.
如果你写var cars = GetCars(),编译器会查看赋值右侧的类型,在这种情况下可能会IEnumerable<Car>,并给出cars该类型.如果用鼠标悬停在变量上,您甚至可以在变量的后续使用中看到它.
如果您更改集合的类型而不必因为使用而更改代码var,请考虑这些不同类型的集合可能具有共同点的事实,使您可以对它们执行相同的操作.可能是IEnumerable你在foreach循环中使用它们.
因此,您也可以将这些集合公开IEnumerable,因此您的类的用户不会过多依赖某个实现.
Gus*_*uss 12
我从不喜欢"将变量的类型放在其名称中"的方法 - 我真的认为它干扰了源的顺利读取.我认为代码应该像故事一样阅读,因此对我来说,一组汽车(我不在乎它是否实现为数组,链表,堆,集或其他)的命名是完全合理的. "汽车":
foreach (Car currentCar : ParkingLog.getCars()) {
stolenCars.add(currentCar);
}
fencer.cars = stolenCars;
适合我.
Jar*_*Par 12
就个人而言,我尽可能避免在变量名中使用集合的类型.它可能看起来不错,但这是一个不可执行的约束,其他开发人员会随着时间推移而陷入困境.如果变量的类型对于特定操作非常重要,我会考虑重写代码...
或者换句话说,我不喜欢匈牙利的表示法.
Sco*_*ttS 12
我通常从多元化开始(例如汽车).通常你也会有一个单数形式的局部变量(例如汽车),有时用两个非常相似的变量名读取代码会很尴尬,在这种情况下我会找到一个变量的新名称.
我几乎从不使用carArray,更可能是allCars,或者选择适当的汽车.
Mat*_*nes 12
喜欢汽车到汽车,但汽车可能不是你想要的.哪辆车？
除了少数几种情况(总是有那些讨厌的例外),汽车等变量名称的描述性不够.
您当然不应该将类型名称添加为变量名称的一部分 - 几乎就是您提到的原因.就个人而言,如果我有一个Car对象的集合,我只是称之为收集汽车 - 复数传达的事实是不止一个没有透露类型,这是不必要的.
作为学习的一部分,我一直在将包含变量类型的变量命名为变量.我可以在代码中的某个地方看到carArray作为提示,它是数组.但是你的问题提出了一个非常有效的观点,即如果你以后改变它,那么你必须追查所有这些引用,这可能是一个很大的噩梦.根据Matthew Vines的回答,"allCars","brokenCars",我看到了命名变量的智慧.我想我会从现在开始更频繁地做这件事,因为我的编码有所改进.