更少的代码行总是更好吗？ [重复]

var result = methodOne(methodTwo(a, methodThree(b)), c, d);

var result3 = methodThree(b);
var result2 = methodTwo(a, result3);
var result = methodOne(result2, c, d);

#1 楼

用外行的话来说：

重要的不是行数，而是代码的可读性。


任何傻瓜都可以编写计算机可以理解的代码。好的
程序员编写人类可以理解的代码。 （M. Fowler）


在您给出的示例中，第二个绝对更易于阅读。

源代码供人们阅读。
/>
此外，中间值使代码更易于调试。

另一方面，代码单行代码有助于向其他人表明您“很聪明”并且您可以不在乎。

#2 楼

这取决于您的示例，而决策对您的示例没有用。

在您的特定示例中：

如果中间值的名称实际上传达了含义，而名称却没有使它们明显用来计算中间值的方法和参数，那么它们有助于理解代码。 ，因为它们是需要跟踪的附加状态。即使它们是不可变的，它们也会迫使您考虑是仅使用一次还是在不同的地方使用它们。

#3 楼

Code with as few lines as possible is definitely the best code and every semi-colon you see is basically the developer admitting they weren't clever enough to use advanced constructions like the comma operator or short-circuiting operators to keep the line going as long as possible like you can say `(x++ && false) || y += 2` instead of `x++; y += 2` and the first variant is just so much more concise and clearer as you can tell because it contains no semi-colons honestly I almost threw up writing the second one I mean who wants to use a character whose name contains a word related to your butt that's just dumb and anyways semi-colons introduce lots of vulnerabilities like what if you typed `while(true) ;` that would just keep running forever and so its clearly better to have no semi-colons to avoid problems like that overall I'd say programmer salaries should be inversely proportional to the number of newlines and semi-colons in their code because everyone knows as soon as you start using a metric like that it starts working even better than before you incentivized it

#4 楼

用代码行衡量编程进度就像按重量衡量飞机建造进度。 （比尔·盖茨）


当然，更少的行并不总是更好。但是以我的经验，就可读性和可维护性而言，更少的行通常比更多的行好。当然也有例外，您的示例可能就是这样的例外。

制造飞机需要重量。但是应该在正确的位置。

#5 楼

在第一个版本中，很难看到将哪些参数传递给了哪种方法。因此，第二个版本显然更好。但是，在其他情况下可能并不那么明显。

第二个版本的主要区别是它允许您命名中间值。在某些情况下，使用此名称对于理解代码至关重要。 >

#6 楼

看来您正在使用JavaScript，它对参数的更改如此之小。但是，您应该通过添加空格和注释使单语句版本尽可能可读。

//Do X, Y, Z....
var result = methodOne(
    methodTwo(
        a, 
        methodThree(b)
    ), 
    c, 
    d
);

#7 楼

更少的代码行总能带来更好的结果吗？

总之根本不是。较长的一个，不是，因为要视情况而定。


我要缩短代码多长时间？如果代码不适合屏幕，将其缩短通常会使其更具可读性
单行完成了多少？如果可以通过10个对象进行访问，那么将其分为多行肯定是个好主意
哪个更好？编写长标准版还是使用棘手的语法糖或库函数？有多少人知道糖/功能？正则表达式就是一个很好的例子。使用单个正则表达式，您可以完成很多行代码，但是有时要花几个小时才能理解单个正则表达式。但是，有一些正则表达式已被广泛使用并且可以在Google上搜索。

以下哪种编程风格更好？ 。如果您需要调试发生的情况，则可以检查变量并设置断点。

另一方面，我不喜欢使用过多的局部变量，因为我必须发明他们的名字。我讨厌这样的名字作为result1 / 2/3，因为一段时间后，我不知道这是为了什么。但是我不想花太多时间来发明名称...第一个例子（对我来说）实际上更具可读性，因为第二个例子中的变量名不好。第一个代码，在需要调试时将其转换为第二个代码。解释名字。只有这样，代码才能更容易阅读。

#8 楼

我的经验法则是将每个操作放在自己的行上。在调试器中单步执行代码时，这特别有用。我还喜欢在将操作的结果传递给变量之前将其分配给变量，以便可以中断并检查其内容。所以我会去

var result = methodOne(methodTwo(a, methodThree(b)), c, d);

如果我没记错的话，我会去.Net JIT编译器将以相同的方式编译这两个示例。

或者，我会在解释我在做什么的那一行之前写一个非常详细的注释。

#9 楼

我怀疑每个人都想听到的是“否”。一个可怕的名字。我发现第一个版本比第二个版本清晰得多。

但是，如果您可以给变量起一个名字-这些名字不仅提供了数据的来源，还提供了更多信息，那么可能会更好。这一切都取决于实际情况。

#10 楼

在这个特定示例中，我发现第一个版本更难阅读，就像阅读(a + f(b)) * c * d这样的简单算术表达式一样。第二个版本没有添加任何有助于理解它的信息（除非变量具有有助于理解复杂过程的有意义的名称）。

我觉得第二个版本有点问题它在分析代码时引入了额外的复杂性。阅读代码的程序员需要考虑是否在其他地方使用了resultThirdMethod或resultSecondMethod，然后才计算result。而且，如果您编写的方法中充斥着此类语句，则没有明确的计算路线，则必须不断检查从何处何处计算出什么。因此，在这种情况下，如果您想要更详细的版本，建议将其封装到单独的函数中：

代码块，以便变量的范围立即可见：

function methodCombined(a, b, c, d) 
    var resultThirdMethod = methodThree(b);
    var resultSecondMethod = methodTwo(a, resultThirdMethod);
    return methodOne(resultSecondMethod, c, d);
}
// ...
result = methodCombined(a, b, c, d);

#11 楼

这取决于读者对这些操作员及其问题领域的熟悉程度。即使所有方法都是算术函数，也可以帮助分解它。 />
与

(let* ((term1 (* b b))
       (term2 (* 4 a c))
       (discriminant (- term1 term2))
       (twoa (* 2 a))
       (top1 (+ b (sqrt discriminant)))
       (top2 (- b (sqrt discriminant)))
       (root1 (/ top1 twoa))
       (root2 (/ top2 twoa)))
  (list root1 root2))

将公式分解成小步是编译器在生成中间代码时所做的工作。 （Fortran：FORmula TRANslator。）

破坏表达式以提高可读性会有所帮助，但请不要“ Fortran it”（过度使用）。

#12 楼

最佳样式是一种使代码更具可读性的样式（对于人类而言，即计算机不在乎）。但是“可读性”在很大程度上取决于谁进行阅读，因此这取决于上下文。但是，这足以回答您的确切问题：“（无论如何）总是更好”吗？然后，不，这取决于上下文。

必须阅读代码的第一个人就是开发人员本人。如果您编写的代码使自己能够在四个星期后阅读和理解它，那么您将做得很好-比行业中大多数开发人员（alas）更好。 />
可以添加一些通用性。阅读代码意味着要用眼睛和大脑。人眼在必须大量移动时，尤其是在垂直移动时，疲劳较快（横向移动不再是问题）。在其他所有条件相同的情况下，使用较少的代码行将使读者能够以较少的垂直眼动来掌握代码，这有点好。

另一方面，大脑中进行的语法分析将希望使用尽可能多的“视觉锚点”，并且将遭受某些活动的困扰，尤其是计算括号。通过缩进将代码分布在更多行上，有助于大脑。这实际上是在眼睛疲劳和大脑疲劳之间进行权衡，我坚持认为，每个人的正确平衡点并不相同。编写丑陋代码的人也是乐于吃坏披萨的人。

#13 楼

您给出了一个不好的例子。

为更好地解决问题而提供的解决方案应具有良好的设计，使其易于理解，并且足以使代码简短。

如果您可以通过延长代码使代码更易于理解，这是可以做的事，但是有一定的局限性。

我总是认为代码既设计好又简短

，您应该专注于一个好的设计，然后找到使代码足够简短的方法，以便阅读该代码的人们可以理解它而无需滚动和滚动滚动。

因此，总的来说，这没有真正好的答案，重要的是如何将代码划分为函数和部分，以及如何使其简短易懂理解。

Bill Gates的报价很好，但也有一些关于完美代码的报价，这是您无法取出任何东西的代码。

#14 楼

我认为，这就是您要决定每种情况下哪种工作方式的问题之一。决定是否应将特定结果存储在中间变量中，这是成为程序员的一部分，也是技术的一部分。您可以在工作场所使用已获得的技能以及编码标准。 ，而且在2B中间接使用匿名数组的时间过长和间接）。但是，您无法真正提出任何详尽的模式列表，在其中可以规定一种方法来替代另一种方法-随着编程艺术的发展，新情况一直在出现。

#15 楼

我想说两个示例同样不好，但这仅仅是因为示例代码不足。为了能够说出两者中的哪一个更好，您需要提供一个真实的例子。

源代码行数与代码质量之间绝对没有关联。 br />
假设我们忽略了显而易见的事实，即代码需要执行应做的事情，那么最重要的方面是它易于被读者理解。实现此目的的“经典”方法是添加描述代码功能的代码注释。以我的个人经验，最好将描述性标识符用于方法，变量和常量。

例如，如果您看到这样的源代码序列，您将立即理解它应该做什么。 ，然后您可以检查各个方法和变量，以（希望）能够轻松地确定它们是否应执行其应做的事情：完全不需要添加任何评论。从实际代码中不容易理解的注释是什么？这是要争取的事情-无需在代码中添加注释以描述其功能。

这不是很难做到的事情。它所需要的只是考虑您真正要完成的工作，并从功能的角度命名标识符。

#16 楼

比可读性更重要的是可维护性，因为我们阅读代码的主要原因是维护代码。
维护经常意味着由于需求的大小变化而对代码进行更改。考虑可能会有什么需求变更，并尝试使其尽可能容易地完成。如果您可以带领维护者使用相关代码，并让他们以最少的编辑量进行更改，那么他们会认为您是一名优秀的程序员！正确性，请确保您清楚其正确性的理由。
如果人们怀疑您代码的正确性，他们很可能会重新编写代码，这很可能会破坏代码。
以防止

此外，请务必解释与性能相关的决定，因为好的代码被破坏的一种方法是通过错误地尝试重新编写以使其更快。

#17 楼

return ($this->main->context != "ajax" || in_array($this->type, $this->definition->ajax)) ? eval('return method_exists($this,"Show'.ucfirst($this->type).'") ? $this->Show'.ucfirst($this->type).'('.(count($args) ? join(",",array_map(create_function('$a','return (is_numeric($a) || preg_match("/^array/",$a)) ? $a : "\"".$a."\"";'),$args)) : "").') : null;') : '';

我在一段时间前继承的项目中碰到了此代码。我认为这很好地说明了为什么尝试使用尽可能少的行是一个坏主意。这是完全不可读的，无法调试。

#18 楼

进行拼写不仅可以提高可读性，而且还可以提高可写性。提供了源和目标（您无需进行任何内存分配）以及源的宽度和高度。是的，这是一个简单的问题。我建议您先进行操作，然后再查看是否有任何问题。

。

是吗？你测试了吗？由于在面试中被问到了这个问题，所以我也在面试中使用了这个问题，我发现许多程序员会感到困惑。他们会这样写代码

 void Rotate90(const Pixel* src, Pixel* dst, int width, int height) 
 {
    for (int y = 0; y < height; ++y) 
    {
      for (int x = 0; x < width; ++x) 
      {
         dst[???] = src[???];

这就是他们被卡住的地方。他们有时会在白板上花费多达20分钟的时间，试图弄清楚这些东西中发生了什么？区。很多时候，他们认为自己有答案，并且写类似

         dst[x * width + (height - 1 - y)] = src[y * width + x];

的事实是，将width与dst一起使用是错误的。或经常是他们将x和y在一侧或另一侧混合在一起。宽度高和高度宽，这使得引用这些变量令人困惑。我一直希望程序员可以添加一些变量，以使自己更清晰，例如

编写代码容易得多，而且避免错误也容易得多。我觉得如果我看到程序员这样做的话，我会认为他们是明智的，并且会给他们更高的评价。

是的，您可以进行一些优化。那不是重点。是的，最后一条语句中的数学也可以分为几行。那也很好。关键是，增加更多行可以使编写代码的人更容易理解，而不仅仅是以后阅读代码的人。在这种情况下，由于x，y，width和height的含义与x和y的关系不同，因此为每个代码分别设置变量会使代码更易于读写。

继续...同样，能够在调用函数之前检查值通常很有用，特别是如果它是库或系统中您无法使用的函数。如果您这样编写代码

 void Rotate90(const Pixel* src, Pixel* dst, int src_width, int src_height)
 {
   int dst_width = src_height;
   int dst_height = src_width;

   for (int src_y = 0; src_y < src_height; ++src_y) 
   {
     for (int src_x = 0; src_y < src_width; ++src_x) 
     {
       int dst_x = src_height - src_y - 1;
       int dst_y = src_x;
       dst[dst_y * dst_width + dst_x] = src[src_y * src_width + src_x];
     }
   }
 }

vs this

ctx.lineTo(x + Math.cos(angle) * radius, y + Math.sin(angle) * radius);

在第二种样式中，您现在可以停止在width行调试器并检查height和dst。您可能会发现它们是src，这可能会让您检查ctx.lineTo，circleX和circleY实际上是正确的名称，而您在调试器中将无法执行此操作。 （“严格”模式可能会抓住这一点）。它还可以让您轻松记录值/>

var circleX = x + Math.cos(angle) * radius;
var circleY = y + Math.sin(angle) * radius;
ctx.lineTo(circleX, circleY);

我知道有些人会在此示例中大喊大叫，因为您的个人风格希望将吸气剂和吸气剂设为1行，但在调试时还是听我说的，具体取决于调试器，在第一种样式中，如果您在NaN或x上设置了断点，则调试器将无法检查angle或radius或age，因此您将无法在函数返回要返回的内容或对象之前进行检查参考。在第二种样式中，您可以在name行上放置断点，并且可以检查所有内容。

这个答案的重点是，更多行通常不仅有利于可读性。它通常还具有可写性和调试性。

#19 楼

事实上，我走得更远，说更少的代码行很少变得更好。

现在，这并不是说不要封装方法调用等，而是在上面的示例中，当进行调试时-很难像这样进行内联时很难看到methodThree和methodTwo的结果。调用并分配给局部变量的许多小方法可以提高可读性，增强可维护性并且没有实际成本，因为编译器会很高兴地优化掉。

#20 楼

从基础上思考。为什么我们要编写代码，当我们想添加一些功能并将其交给另一位开发人员时，他能否理解您的代码，为什么结构很重要，为什么一个人应该遵循基本的标准准则？

答案如下：



为什么要在代码中添加注释。
对于开发人员（谁可以利用？这个小的文档（了解代码和例程功能），计算机或解码/编码系统仅绕过注释，仅处理实际代码。例如：开发包和minifest版本，



如果使用第二个选项，它易于阅读和扩展，并且新开​​发人员扩展我们的代码不需要太多指导。
但是，如果我们使用的是第一个选项，那么编写该代码或可以理解其目的的人却很少，而对整个团队的了解却很少。我们正在快速开发周期中工作，我们需要在不同的项目上工作，并且没有太多时间与其他部门进行协调，因此在这种情况下，第二种方法行之有效，另一名开发人员可以轻松地扩展功能。都是关于依赖的：我们致力于代码的模块化，其中成千上万的开发人员从事着成千上万的函数，他们只知道返回什么，传递给函数什么以及将哪个变量分配给什么以及为什么分配。



对于单个用户或小型程序，当团队一起工作时，第一种方法是可行的，但是当人们在远程工作时该做什么，这就是您可能会选择第二种方法的地方，即优化另一种缩短代码的技术，只是在我们对输出感到满意之后才实现。其他像第二种方法那样的程序开发人员，新人们也可以以此为指导或编辑程序，

计算机可以理解0和1，而人类可以理解注释

，所以我喜欢第二种方法，它可以帮助开发人员了解循环或函数内部发生的事情
例如：**假设您正在处理某些项目，您使用第一种方式，在某些情况下，您还有另一个任务，而另一个开发人员正在处理您的代码，他是否理解？它不是关于简单性或如何编写文档的问题，而仅仅是关于**当他想通过无忧支持来更新代码时如何将代码扩展到我们的合作伙伴。
第二种方法非常适合合作伙伴，开发人员和第一种选择当我们在Web平台上工作时，或在代码大小很重要的情况下编写脚本时，该脚本都能很好地工作。写评论时写评论。当您回到原来的状态并且不了解代码在做什么时，它将为您节省三个月的宝贵时间。同样，当您的同事真正了解您的工作并且可以轻松扩展/重构或修改您编写的代码时，他们也会赞美您。
但是请不要过度使用它。

如果需要减少代码行，那么请继续执行很多行。但是请不要这样做，以免键入更少的行，使您不得不添加注释来解释您的代码。它应该尽可能不言自明。

#21 楼

那么

var result = methodOne(   methodTwo(    a, 
                                        methodThree(b)
                                   ),
                          c,
                          d
                      );

下降的IDE可能会进一步改善它，打印与花括号匹配的行。

#22 楼

简而言之，对于大多数普通人来说，人的大脑最多只能容纳7种不同的东西。这是给普通人的，这是平均水平。 （恐怕我还没有找到我的陈述的来源） / functions / operations。

例如：

rotate(translate(rotate(translate(circle,50,0),0,10,pi),-50,0),0,10,pi)

真的很难理解发生了什么，令人惊讶的是这行绝对几何意义上没有什么：

circle = translate(circle,50,0)
circle = rotate(circle,0,10,pi)
circle = translate(circle,-50,0)
circle = rotate(circle,0,10,-pi)

这也是为什么也容易读取少于40行代码的函数的原因。

#23 楼

这两个示例实际上都是不好的。

如果methodOne失败了会怎样？如果methodTwo失败了怎么办？如果methodThree失败了怎么办？您显然在这里省略了错误检查以保持清晰度，但这是很重要的一点-添加错误检查将添加更多的代码行（靠它自己可以回答您的问题），因此永远不应查看实际执行某些操作的有意义的代码额外行是一件坏事。

除此之外，我还是喜欢第二个例子。之所以这样，是因为它更易于维护。例如，如果将来的需求需要，可以更轻松地在对methodTwo和methodThree的调用之间插入对methodTwoPointFive的调用。