编码指南：方法不应包含超过7个语句？

我一直在浏览《AvSol编码指南》（C＃），我几乎同意所有内容，但我真的很想知道其他人对一个特定规则的看法。

AV1500

方法不应超过7条语句需要7条以上语句的方法执行的操作过多或职责过多。它还需要人的头脑来分析确切的语句，以了解代码在做什么。用不明原因的名称将其分解为多种小型且重点突出的方法。

你们大多数人都遵循这个规则吗？即使可以大大提高可读性，即使创建新方法（您的代码仍然是DRY）几乎没有什么余地？而且您的电话号码仍然低至7吗？我倾向于10。

我并不是说我到处都违反了这条规则，相反，我的方法体积小且专注于95％，但我说你永远不应该违反这条规则，这真的让我感到震惊。

我真的只是想知道每个人对永不违反此规则的看法（在编码标准上为“ 1”-永不这样做）。但是我认为您很难找到没有的代码库。

对我来说，这是“标准气味”。每当我看到编码标准中有特定限制时，我都会担心。您几乎总是遇到一种方法需要大于标准允许的情况的情况（无论是行长/计数，变量数，出口点数等）。标准应更像准则，并留有足够的回旋余地以行使良好的判断力。不要误会我的意思，拥有标准是很好的，但是它们不应该成为“代理的微观管理”。

通常，将内容拆分为小方法是个好主意。但是重要的是在合理的地方进行拆分。

如果拆分没有意义，请不要拆分。对于某些过程或GUI代码，通常是这种情况。

史蒂夫·麦康奈尔（Steve McConnell）在《代码完整》中指出，使用简短方法时，您的工作效率并不总是更高。如果在没有意义的情况下进行拆分，则会给代码增加复杂性而没有任何好处。

像往常一样，最好记住为什么存在约束，以便您可以在不适用约束时学习。在大多数代码中，这些方法会很简短，或者您可能对DRY或关注点分离有疑问。但是，如果不是这样，那很好。

应该将其视为经验法则。

诸如“不超过80（100,120）列的文本”，“每个方法一个出口点”，“不超过2个嵌套级别”之类的东西，我称之为代码气味指示器的阈值。如果您偶尔违反它们，那并不一定意味着代码是错误的。如果发现自己始终违反它们，则代码中会有些气味，您不妨暂停一下并重新考虑您的方法。

对我来说，最重要的标准是：“此代码可理解吗？”，“是否重复？”，“是否在逻辑位置分解？”，“是否松散耦合？” 还有更多，但我认为可以通过记住Donald Knuth的建议来总结基本思想：“程序应由人类读取，并且只能由计算机执行。”

我从来没有花时间来实际计算方法中的语句数，但是我确实致力于编写干净地执行一个明确目标的方法。只要您的代码干净，可读并且遵循DRY和“ 单一职责”原则，您就可以完成工作。我认为，为了强制执行七语句限制而将方法任意分开可能会使您的代码难以读取/难以维护。

大概

这类规则不应该从字面上理解。他们本可以说“ 方法应该简短 ”。但是，有些人将其解释为“少于1页”，而其他人则将其解释为“最多2行”。

我认为他们说“ 7句话”是为了给您一个大概的想法（尽管我认为他们应该说“大约7”）。如果您偶尔需要9点，请不要流汗。但是，如果您的目标是20，您将知道自己不在此规则的正确范围内。

7是一个完全任意的数字，绝对没有意义。

循环复杂度是一个比语句数更大的问题。我见过在一个方法中有100条语句的代码（我认为这很糟糕），但是它的循环复杂度为1，实际上只做1件事。只有很多步骤。我们讨论了将其拆分为较小的方法，但是这些方法只能由这一方法调用。

尽管这是一个极端的情况，但关键是您需要保持代码DRY和较低的循环复杂度。这比方法中的行数更为重要。

以switch / case语句为例。如果您有7个以上的可能值，是否需要将评估分为多种方法？当然不是，那将是愚蠢的。

人为地将代码分成更多的方法，只是为了使语句数保持在7以下，只会使您的代码变得更糟。

准则应为：每个方法应做1件事，并使代码保持DRY。

好吧，这取决于一点。我写了很多访问数据库的代码。在许多情况下，用于异常处理的样板代码超过七个语句。我说最好的准则是确保您的功能具有一个目的

一切都是权衡。提议的方法的问题-重构为几个方法和类，以使每个方法都简短-是尽管由于不同的原因，但如果将其极端化，则会导致无法阅读的代码。

想象一下一种方法foo()可以执行7件事。您可能会认为7件事太多了。在许多情况下，也许您是对的。另一方面，这7件事可能紧密相关。逻辑可以顺畅地流动并像散文一样阅读；实际需要时，您可能会很容易理解它。最终可能会更糟糕的是将这7件事分散在一个大型的源代码树中，因此，如果您foo()不看7个不同的地方，就不知道它的作用。

许多人脑子里有了这样的规则，结果就是我认为的OO面条。一切都是整齐的，以自己的小方法或类装箱，每个地方都发生原子的微交易。但是不可能重新了解这样的代码库并知道它在做什么。你迷路了。

这不是一个坏准则。只要将方法和类进行分组并且相互关联得很好，我就不会后悔将它们拆分开（我从来没有发现我有太多方法）。

诀窍是不要将其垂直拆分（只需将一种方法捏一点，然后再开始一种新方法即可）。就像单元测试一样，技巧是从一开始就牢记这样的规则，以便您实际上可以更好地进行设计，将3或4条语句从中间方法传递给另一种方法，因为进行方法调用比您描述的要好代码中间的那3或4条语句。

这种拆分，即使它是任意的并且仅使用一次，也可能由于新的代码清晰度而在以后导致更好的重构，对于较小的类也是如此。

像对待单元测试一样思考它。如果您尝试在事实之后添加单元测试很困难，有时似乎是不可能的，但是如果从一开始就进行设计，那么实际上会使所有代码变得更好。

摘要？如果将“使用少于7条语句”的设计气味与“我使用7条以上语句”的代码气味进行比较，则宁愿消除该代码气味。

哇！我从没想到会在一个简单的指南上找到如此激烈的讨论，该讨论粗略地说您的方法应该很小。因为他们一直是希望他们的准则明确的开发人员，所以我选择7是因为这听起来像是一个不错的门槛。

你们中有些人已经在文档开始处引用了免责声明。但需要明确的是，本文档代表了一些准则，旨在帮助您编写更好的代码和设计更好的系统。我从来没有说过，即使将准则标记为第1级，任何事情都应该成为规则。这些级别只是使用本文档一段时间的许多人的集体意见。

我也从未声称自己是专家。但是我从事该行业已有15年了，大约有4年C ++经验和11年C＃经验。它最初基于Industrial Strength C ++，但是从那时起，我一直在社区的投入下对其进行完善。

无论如何，我要提出的观点是，您应该继续自己考虑。如果您认为这7条声明指南没有用，则可以延长它。哎呀，我什至不时违反该准则。我只是认真地违反它并接受后果。

首先：这是一个准则，而不是一条规则。它被称为准则，因此请按原样对待。这意味着您也需要自己的判断（一如既往）

除此之外，我可以想到许多不遵守此约束的良好代码示例。即使只是一个准则，也很糟糕。

我同意我上面的说法。这只是一个准则，在一个完美的世界中，所有东西都是对象，可以在每个程序中重复使用，而世界将是一个美丽的地方。并非总是如此，有时这会导致大量开销或资源浪费。您还需要记住这一点。

当您将异常处理添加到混合中时，这非常愚蠢。

在“尝试，捕获，最后”之后，每个方法剩下四个语句！

还要考虑一个20字段表单的方法“ validateForm”，即使您用单独的方法处理所有单独的验证，您仍然有20个字段验证方法要调用。根据这些指导原则，您将最终得到一些毫无意义的拆分，例如“ validateTopOfScreen”，“ validateMiddleOfScreen”和“ validateBottomOfScreen”。

问题是将“规则”与“准则”混为一谈。必须遵守规则-准则是建议，旨在使您考虑自己在做什么以及是否真的可以以更好的方式完成。

我想说的是，平均而言，大多数编程可能会通过遵循准则得到改进，但总有一些情况是，严格遵循准则会导致比计划解决的问题更多。这就是为什么它们不作为规则呈现，而是准则的原因。

先前的答复者表明，指南的编写者从未打算将其原则用于教条，而是在其文档中包含对此的说明。

我同意上面的评论。7对我来说是任意的，在某些使用ruby的语言中可能有用，但是对于C＃，Java，C ++等语言，我怀疑这种“ 7行”约定。让我举一个例子。我当前的应用程序有22个文本字段，我进行服务器端验证。该方法称为validateInput（），我的喜好是验证一个方法本身中的所有字段，除非我已经验证了诸如checkEmailFormat（）之类的复杂对象。所以基本上我的validateInput方法代码是108行，偶尔会调用复杂的验证。

现在，假设我调用了25种方法来验证每个字段。如果有新的开发人员来，他将不得不进入和退出主要方法以跳过25种方法，而这些方法又可能会调用其他方法。他注定会在大型项目中迷路。

为了使代码清晰，我真正要做的是提供清晰的注释，这些注释基本上说出了这4行在做的事情-

validateInput（UserObj用户）{

//验证名字.............

//验证姓氏...... ......

//验证电子邮件..... //太复杂，无法检查电子邮件格式的常规表达式checkEmailFormat（）; .......

等等.. }

坏规则。有了用于异常处理，设置数据库字段，验证的代码，大多数方法怎么会在七个语句之下？我们不应该做内联lambda函数吗？

代码行是复杂性的任意计数。使用扩展方法，我可以创建如下代码

                Parallel.ForEach(regions, region => {   Console.Write(region.Resorts.Where(x => x.name == "Four Seasons").OrderBy(x => x.RegionId).ThenBy(x => x.ResortId).ThenBy(x => x.name).ToList());   });

所有初级程序员都必须遵守这一原则。这将迫使他们考虑自己正在忙的事情的结构，而不是仅仅添加越来越多的行代码。

我目前正在寻找一种包含550行代码的方法，其中包含许多if else语句，然后继续并将其织入其中。废话 只是程序员被迫考虑自己在做什么...