简洁在什么时候不再是一种美德？

最近的错误修复要求我检查其他团队成员编写的代码，在这里发现了这一点（它是C＃）：

return (decimal)CostIn > 0 && CostOut > 0 ? (((decimal)CostOut - (decimal)CostIn) / (decimal)CostOut) * 100 : 0;

现在，有充分的理由进行所有这些强制转换，这仍然很难遵循。计算中有一个小错误，我不得不解开它以解决问题。

我从代码审查中知道了此人的编码风格，他的方法是较短的总是更好。当然，这里还有价值：我们都已经看到了不必要的复杂的条件逻辑链，这些逻辑可以与一些位置合理的运算符一起整理。但是他显然比我更擅长追随运营商，他们陷入了一个单一的问题。

当然，这最终是样式问题。但是，是否有任何关于识别代码简洁性不再有用并成为理解障碍的观点的写作或研究？

_{进行强制转换的原因是实体框架。数据库需要将它们存储为可空类型。小数？不等同于C＃中的Decimal，需要进行强制转换。}

回答有关现有研究的问题

但是，是否有任何关于识别代码简洁性不再有用并成为理解障碍的观点的写作或研究？

是的，这方面已有工作。

要了解这些内容，您必须找到一种计算指标的方法，以便可以在定量的基础上进行比较（而不是像其他答案一样，仅基于智慧和直觉进行比较）。研究的一种潜在指标是

循环复杂度 ÷代码源代码行（SLOC）

在您的代码示例中，此比率非常高，因为所有内容都已压缩到一行。

SATC已发现，最有效的评估是尺寸和[Cyclomatic]复杂度的组合。具有高复杂度和大尺寸的模块往往具有最低的可靠性。尺寸小，复杂度高的模块也存在可靠性风险，因为它们往往是非常简洁的代码，难以更改或修改。

链接

如果您感兴趣，这里有一些参考资料：

McCabe，T.和A. Watson（1994），软件复杂性（CrossTalk：国防软件工程杂志）。

Watson，AH和McCabe，TJ（1996）。结构化测试：使用环复杂度度量的测试方法（NIST特殊出版物500-235）。从McCabe Software网站检索：2011年5月14日：http : //www.mccabe.com/pdf/mccabe-nist235r.pdf

Rosenberg，L.，Hammer，T.，Shaw，J。（1998）。软件度量标准和可靠性（IEEE国际软件可靠性工程研讨会论文集）。从宾夕法尼亚州立大学网站检索：2011年5月14日：http : //citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.104.4041&rep=rep1&type=pdf

我的意见和解决方案

就我个人而言，我从来没有重视简洁性，只有可读性。有时简洁有助于提高可读性，有时却不能。更重要的是，您正在编写“ 真正显而易见的代码”（ROC），而不是“仅写代码”（WOC）。

只是为了好玩，这是我的写法，并请我的团队成员编写：

if ((costIn <= 0) || (costOut <= 0)) return 0;
decimal changeAmount = costOut - costIn;
decimal changePercent = changeAmount / costOut * 100;
return changePercent;

还要注意，引入工作变量具有触发定点算术而不是整数算术的令人满意的副作用，因此decimal消除了对所有这些强制类型转换的需要。

简洁性可以减少周围重要事物的混乱，但是当它变得简洁时，将太多相关数据打包得过于密集以至于无法轻易跟随，那么相关数据本身就会变得混乱，您就会遇到麻烦。

在这种特殊情况下，decimal要重复进行强制转换；整体上将其重写为以下内容可能会更好：

var decIn = (decimal)CostIn;
var decOut = (decimal)CostOut;
return decIn > 0 && CostOut > 0 ? (decOut - decIn ) / decOut * 100 : 0;
//                  ^ as in the question

突然，包含逻辑的线短了很多，并且恰好位于一条水平线上，因此您无需滚动即可看到所有内容，其含义也更容易理解。

尽管我无法对此主题进行任何特定的研究，但我建议您代码中的所有这些强制类型转换都违反了“不要自己重复”的原则。您的代码似乎想要执行的操作是将costInand 转换costOut为type Decimal，然后对此类转换的结果执行一些健全性检查，如果检查通过则对这些转换后的值执行其他操作。实际上，您的代码对未转换的值执行完整性检查之一，从而增加了costOut可能保留的值大于零，但小于Decimal可表示的最小非零值大小的一半的可能性。如果代码定义类型变量Decimal来保存转换后的值，然后对这些值进行操作，则代码将更加清晰。

它似乎奇怪的是，你会更感兴趣的比例Decimal的表示costIn和costOut比实际值的比例costIn和costOut，除非该代码也将使用十进制表示用于其他目的。如果代码将进一步使用这些表示形式，那么这将是创建变量以保存这些表示形式的进一步论据，而不是在整个代码中连续进行强制转换。

我查看该代码，然后问：“成本如何为0（或更少）？”。这表示什么特殊情况？代码应该是

bool BothCostsAreValidProducts = (CostIn > 0) && (CostOut > 0);
if (!BothCostsAreValidProducts)
  return NO_PROFIT;
else {
   // that calculation here...
}

我猜是这里的名字：变化BothCostsAreValidProducts和NO_PROFIT适当的。

当我们忘记了达到目的的手段而不是本身的美德时，简洁就不再是一种美德。我们喜欢简洁，因为它与简单性相关；我们喜欢简单，因为更简单的代码更易于理解，易于修改并且包含更少的错误。最后，我们希望代码实现这些目标：

1. 用最少的工作量来满足业务需求

2. 避免错误

3. 让我们在将来做出继续实现1和2的更改

这些是目标。任何设计原则或方法（无论是KISS，YAGNI，TDD，SOLID，证明，类型系统，动态元编程等）都仅在帮助我们实现这些目标的范围内具有美德。

该生产线似乎错过了最终目标。虽然很短，但并不简单。通过多次重复相同的铸造操作，它实际上包含了不必要的冗余。重复代码会增加复杂性并增加错误的可能性。将转换与实际计算混合在一起也使代码难以遵循。

该行涉及三个方面：防护（特殊套管0），类型转换和计算。孤立地考虑每个问题都非常简单，但是由于所有问题都混合在同一个表达式中，因此很难遵循。

尚不清楚为什么CostOut第一次使用它时不会使用CostIn。可能有充分的理由，但是意图并不明确（至少并非没有上下文），这意味着维护人员会警惕更改此代码，因为可能存在一些隐藏的假设。这是对可维护性的厌恶。

由于CostIn在与0比较之前进行了强制转换，因此我假设它是一个浮点值。（如果它是一个int，则没有理由强制转换）。但是，如果CostOut是浮点数，则代码可能会隐藏一个晦涩的被零除的错误，因为浮点值可能很小但非零，但当转换为十进制时为零（至少我相信这是可能的。）

因此，问题不是简洁或缺乏，问题是重复的逻辑和关注点的混淆，导致难以维护的代码。

引入变量以保留强制转换的值可能会增加按代币数量计算的代码的大小，但会降低复杂性，分离问题并提高清晰度，这使我们更接近易于理解和维护的代码目标。

简洁根本不是美德。可读性是优点。

简洁可以成为实现美德的工具，或者像您的示例一样，可以成为实现完全相反的工具。通过这种方式，它几乎没有任何价值。代码应该“尽可能短”的规则也可以用“尽可能淫秽”代替-它们同样没有意义，并且如果没有更大的用途，则可能造成破坏。

此外，您发布的代码甚至都不遵循简短规则。如果用M后缀声明常量，则(decimal)可以避免大多数可怕的类型转换，因为编译器会将剩余值提升int为decimal。我相信您所描述的人只是以简洁为借口。很可能不是故意的，但仍然是。

在多年的经验中，我开始相信最终的简洁就是时间 -时间主导着其他一切。这包括性能时间-程序完成工作需要多长时间-以及维护时间-添加功能或修复错误需要多长时间。（如何平衡这两个代码取决于所执行代码与改进代码执行的频率-请记住，过早的优化仍然是万恶之源。）简短的代码是为了提高两者的简洁性。较短的代码通常运行速度更快，并且通常更易于理解和维护。如果两者都不做，那就是净负数。

在这里显示的情况下，我认为文本的简洁性被误认为行数的简洁性，以牺牲可读性为代价，这可能会增加维护时间。（执行转换可能还需要更长的时间，具体取决于转换的方式，但除非上一行运行了数百万次，否则可能不必担心。）在这种情况下，重复的十进制转换会降低可读性，因为很难做到这一点。看看最重要的计算是什么。我会写如下：

decimal dIn = (decimal)CostIn;
decimal dOut = (decimal)CostOut;
return dIn > 0 && CostOut > 0 ? ((dOut - dIn) / dOut) * 100 : 0;

（编辑：这是与其他答案相同的代码，所以就可以了。）

我是三元运算符的爱好者? :，所以我不予理会。

就像上面所有几乎所有答案一样，可读性应始终是您的主要目标。但是，我还认为，与创建变量和换行相比，格式化可能是实现此目的的更有效方法。

return ((decimal)CostIn > 0 && CostOut > 0) ?
       100 * ( (decimal)CostOut - (decimal)CostIn ) / (decimal)CostOut:
       0;

在大多数情况下，我完全同意圈复杂度的说法，但是您的函数似乎很小且很简单，可以用一个好的测试用例更好地解决。出于好奇，为什么需要强制转换为小数？

在我看来，这里可读性的一个大问题是完全缺乏格式。

我会这样写：

return (decimal)CostIn > 0 && CostOut > 0 
            ? (((decimal)CostOut - (decimal)CostIn) / (decimal)CostOut) * 100 
            : 0;

根据CostIn和的类型CostOut是浮点类型还是整数类型，某些强制转换也可能不是必需的。与float和不同double，整数值被隐式提升为decimal。

可以急着编写代码，但是在我的世界中，上面的代码应该用更好的变量名编写。

如果我正确阅读了代码，则它正在尝试进行毛利润计算。

var totalSales = CostOut;
var totalCost = CostIn;
var profit = (decimal)(CostOut - CostIn);
var grossMargin = 0m; //profit expressed as percentage of totalSales

if(profit > 0)
{
    grossMargin = profit/totalSales*100
}

我假设CostIn * CostOut是整数
这就是我将其写为
M（货币）为十进制的方式

return CostIn > 0 && CostOut > 0 ? 100M * (CostOut - CostIn) / CostOut : 0M;

代码是为人们理解而编写的；在这种情况下，简洁性并不能带来太多好处，而且会增加维护人员的负担。为简便起见，您绝对应该通过使代码更具自记录性（更好的变量名）或添加更多注释来解释为什么如此工作来扩展此功能。

今天，当您编写代码来解决问题时，明天需求改变时，该代码可能会成为问题。始终必须考虑维护，并且提高代码的可理解性至关重要。

精简不再是一种美德

• 有没有事先检查为零的除法。
• 没有检查是否为空。
• 没有清理。
• TRY CATCH vs引发了可以解决错误的食物链。
• 对异步任务的完成顺序进行了假设
• 使用延迟而不是将来重新计划的任务
• 使用不必要的IO
• 不使用乐观更新

如果这通过了验证单元测试，那么就可以了，如果添加了新规范，需要新测试或增强的实现，并且需要“整理”代码的简洁性，那就是问题就会出现。

显然，代码中的错误表明，Q / A还有另一个问题，那就是疏忽大意，因此，存在一个未被发现的错误的事实值得关注。

当处理非功能性需求（例如代码的“可读性”）时，它需要由开发经理定义并由主要开发人员进行管理，并得到开发人员的尊重，以确保正确的实现。

尝试确保代码的标准化实现（标准和约定），以确保“可读性”和“可维护性”的易用性。但是，如果未定义和实施这些质量属性，那么最终将得到上面的示例所示的代码。

如果您不喜欢这种代码，请尝试使团队就实施标准和约定达成一致，并将其写下来，并进行随机代码审查或抽查以确认该约定得到遵守。