| 下面的两种代码编写风格，你更倾向于哪一种呢？ 第1种：
第2种：
尽管这两段代码实现方式区别不大，但是单从代码行数方面考虑，第1种有效代码行数仅为第2种的一半。你更倾向于哪种风格呢？ 这是问答网站Stackexchange（Stackoverflow扩展版）中的一个问题。提问者Ankit是一名Java开发者，他经常被代码审查者要求减少代码行数，审查者认为他应该专注于使用更少的代码来完成同样的工作，而Ankit则希望能够使代码更加清晰，即使这样会增加代码的行数，他认为这不是简单的去除冗余代码的问题，而是有关个人编程风格。 那么LOC（代码行）小的话，对于代码执行有什么影响？如果大的话，又有什么影响呢？下面来看看其他开发者怎么说的。 mattnz认为统计SLOC完全没有必要，与之相比，更应该去统计代码的重要性、可读性和复杂性： 引用 这涉及到软件项目度量的问题，不管目的如何，可以对项目中重要的代码进行衡量。 衡量SLOC（Source lines of code）是否真的重要？当然不，除了混淆编程竞赛外，对于商业组织来说，SLOC从来都不重要，未来也不会重要。 问自己一个简单的问题，减少SLOC是否可以使你的代码更好？SLOC往往被天真地用来衡量项目复杂度，这种情况下，SLOC少的代码也许是好的代码。你应该极力避免去统计那些容易统计的东西（比如SLOC），尝试去统计重要性、可读性、复杂性等难以统计的东西。 Erik Dietrich表示认同代码审查者的建议： 引用 你在代码中所写的每一个语句都是一个技术责任，也是一个潜在的故障点。如果解决同一个问题，你用了10句话，而你的同事只用5句话，那么从出错可能性上考虑，你同事的代码可能会被认为更好，因为你的代码可能更容易出错。 当然我指的是语句，不是代码行。比如下面的代码：
只有一行，但是其中可能会有大量的地方出问题。因此我想说的是，专注于使用最少量的语句来实现（注意是“语句”），而对于代码行，你需要写多少就写多少吧。我认为这也是你的代码审查者所希望的。 我个人认为，还需要取得一个平衡点。正如我说，你所写的每一条语句都是一处技术责任，但如果你使用描述性的名称来命名一个局部变量，使你的代码更加清晰、可读，这样也是好的。我认为你比较容易卷入人们对较小审美差异的争论中，但整体上，我比较认同你的代码审查者的观点，因为这样有利于最大限度地减少可能出错的东西。 Xion更喜欢简洁的解决方案： 引用 代码审查者的建议从字面上来说，不会对程序有什么提高的地方。我比较认同的是——让你的代码做更少的事情。 换句话说，就是要求代码简单。代码是一种责任，而不是资产，因此应该减少它的量。你可以通过一个更直接、更朴实的方式来解决问题。 就像Ken Thompson曾经说的——“我最有效率的一天是扔掉了1000行代码。” jhewlett比较认同提问者所说的“使代码更加清晰，即使这样会增加代码的行数”： 引用 我见过很多简洁的程序，代码行数相当少，但是从这些代码中不能马上看出它们的意思。 可读性为王，因为其他开发者还要维护你的代码。 我认为最好是——将更短的方法作为目标，不要单单追求减少代码行，而是让代码“短”到只做一件单一的事情。 Joshua Volearix认为简洁、容易阅读的代码是开发中的最重要的因素： 引用 下面的代码我完全无法接受：
但是我发现如果将下面的代码：
改变如下：
这样即减少了代码行数，又不牺牲可读性。 至于修改后如何影响代码执行？我反正没注意到性能的增加或减少。比起使用多少行代码来实现，更重要的是使用了多少过程来实现。我之前看到过一些很简洁的代码，但是它们的执行效率比不上那些拥有更好的设计流程但行数多的代码。 Vitim.us认为更少的代码更易读，但Joe提出了异议： 引用 我不认为更少的代码==代码更易读。然而现实中，大段的代码往往没有经过合理的设计。因此，我认为要求减少代码行，可以迫使程序员想出更好的设计。 更详细的讨论可以参阅原帖：How important is it to reduce the number of lines in code? |
