我读过（例如从Martin Fowler那里）我们应该在OOP的（短）方法中使用保护子句而不是单个返回。我还读到（从我不记得的地方）在可能的情况下应该避免使用其他条款。
但是我的同事（我在一个只有3个人的小团队中工作）强迫我不要在一个方法中使用多个返回，并尽可能多地使用 else 子句，即使 else 块中只有一个注释行。
这使我很难遵循他们的编码风格，因为例如，我无法在一个屏幕中查看方法的所有代码。当我编码时，我必须首先编写guard子句，然后尝试将其转换为具有多个返回的表单。
是我错了，还是我该怎么办？
这是一个有争议的、纯粹的美学问题。
在C语言和类似语言中，历史上一直避免早期返回，因为可能会错过资源清理，而资源清理通常放在函数的末尾，以防早期返回。
鉴于Java有例外，最后尝试，捕获，没有必要担心早期回报。
就个人而言，我同意你的观点，因为我经常提前返回 - 这通常意味着更少的代码和更简单的代码流，更少的if/else嵌套。
Guard 子句是一个好主意，因为它清楚地表明当前方法在某些情况下不感兴趣。当你在方法的一开始就清楚它不处理某些情况（例如，当某些值小于零时），那么该方法的其余部分就是其职责的纯粹实现。
有一个更强的 guard 子句案例 - 当某些参数不可接受时（例如 null）验证输入并引发异常的语句。在这种情况下，您不想继续执行，但希望在方法的开头抛出。这就是 guard 子句是最佳解决方案的地方，因为您不希望将异常抛出逻辑与要实现的方法的核心混合在一起。
在谈论引发异常的 guard 子句时，下面是一篇关于如何使用扩展方法在 C# 中简化它们的文章：如何降低循环复杂性：保护子句。虽然该方法在 Java 中不可用，但它在 C# 中很有用。
