我有这两段代码,哪一个更易读?
前锋
decimal technicalPremium = 0; foreach (Risk risk in risks) { technicalPremium = technicalPremium + risk.TechnicalPremium; } return technicalPremium;
林克
return risks.Sum(risk => risk.TechnicalPremium);
我有这两段代码,哪一个更易读?
前锋
decimal technicalPremium = 0;
foreach (Risk risk in risks)
{
technicalPremium = technicalPremium + risk.TechnicalPremium;
}
return technicalPremium;
林克
return risks.Sum(risk => risk.TechnicalPremium);
如果编写代码的团队知道 Linq 版本做了什么并且知道它的内部工作原理,那么它就更具可读性。
使用您喜欢的任何一个,但将其隐藏在一个方法中:
return risks.SumTechnicalPremium();
两者都不。第一个比较冗长,可能每个人都能理解。第二个更简洁,即使对linq有一点了解的人也很容易理解。
我想说你可以根据你所处的环境做出选择。
对于可以阅读 LINQ 的人来说,LINQ 一。
对于必须逐步解释代码的人(通过使用较短的智能感知/文档。
与linq一起去。如果你认为它需要解释,一行注释会解决这个问题。随着人们越来越习惯于 linq,对评论的需求将会消失。
LINQ 代码既可读又自记录。
第一个选项对更广泛的人来说更具可读性。第二个选项有一个“进入障碍”,因为读者可能知道并理解 LINQ。它更简洁,因此如果您的受众超过了该进入障碍,可能会更好。
我认为第二种选择更好,因为它应该更有效。然而,正在发生的事情并不那么明显(至少对我而言)。
我会说第一个,因为我不知道 linq。冒着过度记录的风险,我会使用那个对正在发生的事情进行简短描述的文件。或者只是说它对于可能不知道的人来说是 linq。
如果您提供解释其目的的评论,那么我会选择 Linq 选项。
第一个,如果您不了解 Linq。任何开发人员都可以阅读和理解第一个。
这里没有可读性问题。单击总和并按 F1。
林克为胜利。
每种语言都有编写此类代码的最佳方式的约定,因此对于经常使用该语言的人来说,最易读的东西并不是通用的。对于 Java 或普通 C# 程序员来说,第一个选项更具可读性。对于习惯于 LINQ 或函数式编程的人来说,第二个更具可读性。
我不知道 c#,但第二种选择对我来说看起来更干净,我可以理解它的作用(好的,与第一个版本进行一些猜测和交叉检查)。可能是因为一些功能背景。但首先,您必须在 4(!) 个地方寻找技术溢价。如果您只是阅读代码,则第二个更短且更容易理解。
或者
十进制技术溢价 = 0;
foreach (风险中的风险) TechnicalPremium = TechnicalPremium + risk.TechnicalPremium;
返回技术溢价;
我看到人们说他们喜欢第一个“如果你不知道 Linq”。是的,如果你不懂 C#,第一个是不可读的。这不是“哪个更具可读性”的问题,而是“我们使用哪种语言功能更舒服?”的问题。
首先与您的团队就每个人讨厌的语言/框架/工具集的部分进行对话,并宣布它们禁止使用。其他一切都被认为是标准词汇的一部分,每个人都应该流利。这个列表应该放在你的编码标准文档中,就在“从不制作可变值类型”和“不要为非公共成员的琐碎属性烦恼”旁边。
只要 Linq 不在您的“排除”列表中,第二个示例就比第一个示例更具可读性。为什么?因为它声明了代码的意图,而不是仅仅呈现给读者破译的机制。
如果您的目标是使其对可能出现在您之后的“任何人”更具可读性,请使用 foreach。我将“更具可读性”解释为任何具有语言基础经验的人都应该能够掌握。对于不熟悉 linq 并且仍在使用 VS2005 或更早版本的人来说,linq 语法会令人困惑。
我会说第一段代码肯定更具可读性,如果您至少重命名变量 risk 使其具有与类不同的名称,它将更具可读性。如果您重命名数组风险,可能也会更好。
我同意那些说随着 Linq 被更广泛地采用第二个将很容易理解的人的观点。它当然更简洁。
但是,我对调试的难易程度有些担心。单步执行 foreach 中的代码似乎要容易得多,以准确查看它在每次传递中所做的事情。
我认为这取决于您所说的“可读”是什么意思。第一个例子清楚地表明了程序逻辑,任何有编程背景的人都应该可以理解。
对我来说,第二个示例基于上下文更直观(即,您正在获取一个数组(或其他一些集合类型)并在该数组的每个元素上执行一个名为 Sum 的方法)。第二个示例可能变得不太清楚的唯一地方是实际的 lambda 表达式本身,特别是对于那些没有 lambda 经验或已经有函数式编程背景的人。
我认为随着 lambda 在 .NET 编程中变得越来越普遍,这将不再是一个问题。就目前而言,我认为了解如何在 .NET 中使用 lambda 表达式的基础知识需要一个非常小的学习曲线。
第二个,肯定的。有这么大的代码块来做像求和这样简单的事情是没有必要的。我也不知道 LINQ 是什么,但它对我来说是完全可读的。