反转“if”语句以减少嵌套
当我在代码上运行ReSharper时，例如：
if (some condition)
{
Some code...
}
ReSharper给了我上述警告（反转“如果”声明以减少嵌套），并建议进行以下更正：
if (!some condition) return;
Some code...
我想明白为什么这样更好。 我一直认为在方法中使用“返回”是有问题的，有点像“goto”。
方法中的回报并不一定是坏事。 如果代码的意图更清晰，最好立即返回。 例如：
double getPayAmount() {
double result;
if (_isDead) result = deadAmount();
else {
if (_isSeparated) result = separatedAmount();
else {
if (_isRetired) result = retiredAmount();
else result = normalPayAmount();
};
}
return result;
};
在这种情况下，如果_isDead为真，我们可以立即退出该方法。 相反，以这种方式构建它可能会更好：
double getPayAmount() {
if (_isDead) return deadAmount();
if (_isSeparated) return separatedAmount();
if (_isRetired) return retiredAmount();
return normalPayAmount();
};
我从重构目录中选择了这些代码。 调用此特定的重构：使用Guard子句替换嵌套条件。
它不仅是美学的 ，而且还降低了方法内的最大嵌套层次。 这通常被认为是一个加号，因为它使得方法更容易理解（事实上，许多静态分析工具提供了这种作为代码质量指标之一的度量）。
另一方面，它也使得你的方法有多个出口点，而另一些人认为这是一个禁忌。
就我个人而言，我同意ReSharper和第一个团队（用一种有例外的语言，我觉得讨论“多个退出点”很愚蠢;几乎任何东西都可能抛出，所以在所有方法中都有许多潜在的退出点）。
关于性能 ：在每种语言中，两个版本应该是等效的（如果不是在IL级别，那么肯定是在代码执行抖动之后）。 理论上这取决于编译器，但实际上，今天任何广泛使用的编译器都能够处理比这更先进的代码优化案例。
这是一个宗教争论，但我同意ReSharper，你应该更喜欢更少的嵌套。 我相信这超过了来自函数的多个返回路径的负面影响。
减少嵌套的关键原因是为了提高代码的可读性和可维护性 。 请记住，许多其他开发人员将来需要阅读您的代码，而使用较少缩进的代码通常更易于阅读。
先决条件是一个很好的例子，可以在函数开始时尽早返回。 为什么其他功能的可读性会受到先决条件检查的影响？
至于关于从方法返回多次的消极因素 - 调试器现在非常强大，而且很容易找出某个特定函数返回的位置和时间。
在一个函数中有多个返回不会影响维护程序员的工作。
代码可读性差。
链接地址: http://www.djcxy.com/p/86861.html