我读过（例如Martin Fowler），我们应该使用guard子句而不是OOP中（短）方法中的单一返回。我也读过（从某个地方我不记得），其他条款应尽可能避免。我应该用guard子句，并试图避免else子句吗？
但是我的同事们（我在一个只有3个人的小团队中工作）迫使我不要在方法中使用多个返回，并尽可能地使用else子句，即使只有一条注释行别的块。
这使我很难遵循他们的编码风格，因为例如，我无法在一个屏幕中查看方法的所有代码。当我编写代码时，我必须先编写保护条款，然后尝试将其转换为不带多个返回的表单。
我错了吗？我该怎么处理它？
这是有争议的和纯粹的美学问题。
早期回报在C语言和类似语言中一直被避免，因为可能会错过资源清理，通常在函数结束时将其置于早期返回的情况下。
鉴于Java有例外情况并尝试捕获，最终没有必要害怕早期的回报。个人意见，我同意你的意见，因为我经常提前回头 - 这通常意味着更少的代码和更简单的代码流，而更少的if/else嵌套。
让他们阅读http://www.cis.temple.edu/~ingargio/cis71/software/roberts/documents/loopexit.txt，看看它是否会改变主意。 （有他们的想法的历史，但我与你同在。）
编辑：以下是文中的要点。原则上采用控制结构单一退出的原则，而不是观测数据。但观测数据表明，允许多种退出控制结构的方式使得某些问题更容易准确解决，并且不会影响可读性。禁止它会使代码变得更困难，而且更可能成为越野车。这涵盖了各种各样的程序员，从学生到教科书编写者。因此，我们应该允许并适当地使用多个出口。
这篇文章中有太多内容要阅读。你能否提一下这个重要的想法？ – HelloWorldNoMore 2016-05-17 00:04:34
我在多次回归/返回早期阵营，我会游说说服其他工程师这样做。你可以有很好的论据，并且引用了很好的资料，但最终你只能做出决定，建议妥协，做出决定，然后作为一个团队工作，这一切都可以实现。 （虽然时常回顾这个话题也不是问题）
这真的只是归结为风格，而在事物的宏伟计划中，这是一个相对较小的风格。总的来说，如果你能适应任何一种风格，你就是一个更有效的开发者。如果这真的“很难......按照他们的编码风格”，那么我建议你去研究它，因为最终你会成为更好的工程师。
我曾经有一位工程师来找我，并坚持让他免费遵循他自己的编码风格（而且我们有一套非常简单的指导方针）。他说，既定的编码风格伤害了他的眼睛，并使他难以集中注意力（我想他可能甚至说过“令人恶心”）。我告诉他，如果他要去处理很多人的代码，而不仅仅是代码他写道，反之亦然。如果他不能适应以商定的方式工作，我不能使用他，也许这种类型的合作项目不适合他。巧合的是，之后这个问题就不那么严重了（尽管每次代码审查仍然是一场战斗）。
保护条款是一个好主意，因为它清楚地表明当前方法在某些情况下不感兴趣。当你在方法的最开始清理它不处理某些情况时（例如当某个值小于零时），那么剩下的方法就是纯粹履行其职责。
有一个更强大的guard子句 - 当某些参数不可接受时验证输入并抛出异常的语句，例如，空值。在这种情况下，您不想继续执行，但希望在方法的最开始时抛出。那就是guard子句是最好的解决方案，因为你不想把异常抛出逻辑和你正在实现的方法的核心混合在一起。
在讨论引发异常的guard子句时，以下是一篇关于如何使用扩展方法在C＃中简化它们的文章：How to Reduce Cyclomatic Complexity: Guard Clause。虽然该方法在Java中不可用，但它在C＃中非常有用。
With _“我无法在一个屏幕中查看一个方法的所有代码”_，你是否意味着他们已经如此 - 如此之多以至于代码已经缩进以至于它超出了屏幕？或者，如果 - 否则需要更多的空间，所以方法比需要的更长（更高）？ B.t.w.我喜欢守卫子句。 – KajMagnus 2015-08-25 06:52:15
*“即使在else块中只有一条注释行”* - 其中一个源代码来自“代码完成”一书。这听起来像是他们对于应用它太过于教条。 – icc97 2015-09-03 08:39:04