“写更少的代码” 是否真的有必要？

资讯频道 → 研发管理

7顶
2踩

2013-04-12 18:23 by 副主编 wangguo 评论(29) 有18320人浏览

代码行编程工作 LOC 项目复杂度

声明：ITeye资讯文章的版权属于ITeye网站所有，严禁任何网站转载本文，否则必将追究法律责任！

下面的两种代码编写风格，你更倾向于哪一种呢？

第1种：

public static void happyBirthday(int age)
{  
        if ((age == 16) || (age == 21) || ((age > 21) && (((age % 10) == 0) || ((age % 25) == 0))))        
    {
        System.out.println("Super special party, this year!");
    }
    else
    {
        System.out.println("One year older. Again.");
    }
}

第2种：

public static void happyBirthday(int age)
{
    boolean sweet_sixteen = (age == 16);
    boolean majority = (age == 21);
    boolean adult = (age > 21);
    boolean decade = (age % 10) == 0;
    boolean quarter = (age % 25) == 0;

    if (sweet_sixteen || majority || (adult && (decade || quarter)))
    {
        System.out.println("Super special party, this year!");
    }
    else
    {
        System.out.println("One year older. Again.");
    }
}

尽管这两段代码实现方式区别不大，但是单从代码行数方面考虑，第1种有效代码行数仅为第2种的一半。你更倾向于哪种风格呢？

这是问答网站Stackexchange（Stackoverflow扩展版）中的一个问题。提问者Ankit是一名Java开发者，他经常被代码审查者要求减少代码行数，审查者认为他应该专注于使用更少的代码来完成同样的工作，而Ankit则希望能够使代码更加清晰，即使这样会增加代码的行数，他认为这不是简单的去除冗余代码的问题，而是有关个人编程风格。

那么LOC（代码行）小的话，对于代码执行有什么影响？如果大的话，又有什么影响呢？下面来看看其他开发者怎么说的。

mattnz认为统计SLOC完全没有必要，与之相比，更应该去统计代码的重要性、可读性和复杂性：

引用

这涉及到软件项目度量的问题，不管目的如何，可以对项目中重要的代码进行衡量。

衡量SLOC（Source lines of code）是否真的重要？当然不，除了混淆编程竞赛外，对于商业组织来说，SLOC从来都不重要，未来也不会重要。

问自己一个简单的问题，减少SLOC是否可以使你的代码更好？SLOC往往被天真地用来衡量项目复杂度，这种情况下，SLOC少的代码也许是好的代码。你应该极力避免去统计那些容易统计的东西（比如SLOC），尝试去统计重要性、可读性、复杂性等难以统计的东西。

Erik Dietrich表示认同代码审查者的建议：

引用

你在代码中所写的每一个语句都是一个技术责任，也是一个潜在的故障点。如果解决同一个问题，你用了10句话，而你的同事只用5句话，那么从出错可能性上考虑，你同事的代码可能会被认为更好，因为你的代码可能更容易出错。

当然我指的是语句，不是代码行。比如下面的代码：

void someMethod() {   
someobject.doSomething(someSingleton.getInstance().with().a().lot().of().law().of().demeter().violations()).and().if().that().werent().enough().theres().more();
}

只有一行，但是其中可能会有大量的地方出问题。因此我想说的是，专注于使用最少量的语句来实现（注意是“语句”），而对于代码行，你需要写多少就写多少吧。我认为这也是你的代码审查者所希望的。

我个人认为，还需要取得一个平衡点。正如我说，你所写的每一条语句都是一处技术责任，但如果你使用描述性的名称来命名一个局部变量，使你的代码更加清晰、可读，这样也是好的。我认为你比较容易卷入人们对较小审美差异的争论中，但整体上，我比较认同你的代码审查者的观点，因为这样有利于最大限度地减少可能出错的东西。

Xion更喜欢简洁的解决方案：

引用

代码审查者的建议从字面上来说，不会对程序有什么提高的地方。我比较认同的是——让你的代码做更少的事情。

换句话说，就是要求代码简单。代码是一种责任，而不是资产，因此应该减少它的量。你可以通过一个更直接、更朴实的方式来解决问题。

就像Ken Thompson曾经说的——“我最有效率的一天是扔掉了1000行代码。”

jhewlett比较认同提问者所说的“使代码更加清晰，即使这样会增加代码的行数”：

引用

我见过很多简洁的程序，代码行数相当少，但是从这些代码中不能马上看出它们的意思。

可读性为王，因为其他开发者还要维护你的代码。

我认为最好是——将更短的方法作为目标，不要单单追求减少代码行，而是让代码“短”到只做一件单一的事情。

Joshua Volearix认为简洁、容易阅读的代码是开发中的最重要的因素：

引用

下面的代码我完全无法接受：

void someMethod() {   
someobject.doSomething(someSingleton.getInstance().with().a().lot().of().law().of().demeter().violations()).and().if().that().werent().enough().theres().more();
}

但是我发现如果将下面的代码：

if (boolean == true){
value.prop = option1;
}
else{
value.prop = option2;
}

改变如下：

value.prop =  boolean ? option1 : option2;

这样即减少了代码行数，又不牺牲可读性。

至于修改后如何影响代码执行？我反正没注意到性能的增加或减少。比起使用多少行代码来实现，更重要的是使用了多少过程来实现。我之前看到过一些很简洁的代码，但是它们的执行效率比不上那些拥有更好的设计流程但行数多的代码。

Vitim.us认为更少的代码更易读，但Joe提出了异议：

引用

我不认为更少的代码==代码更易读。然而现实中，大段的代码往往没有经过合理的设计。因此，我认为要求减少代码行，可以迫使程序员想出更好的设计。

更详细的讨论可以参阅原帖：How important is it to reduce the number of lines in code?

对于这个问题，你是怎么看待的呢？

分享到：

7
顶

2
踩

评论共 29 条请登录后发表评论

29 楼 Bactryki 2013-04-22 17:23

shine.xie 写道

佛说，不可说，一说就错。
说“写更少的代码，有必要”，是错误的。
说“写更少的代码，没必要”，也错误的。
那样都执着于概念，一个念头了。
凡事不必执着概念。“一切有为法,如梦幻泡影,如雾亦如电,应作如是观”。
系统有规律可循，而规律本身就是变化的事情。要看系统情况做相应的判断。
从以下楼层中也能看出各种情况各种分析判断了。

说得很对，实事求是才是重点，即能确保自己的编码习惯和风格，又能站在阅读者的立场写出便于阅读的代码，对程序猿的要求是有点高啊~

28 楼 fflame 2013-04-17 14:41

容易理解比数量更重要

27 楼 yyszh 2013-04-16 16:43

如果实现同样的功能，1000行和100行的相对来说，100行的容易读懂，除非100行的代码故意做了混淆处理。

26 楼 yyszh 2013-04-16 16:42

这怎么能绝对化呢。只是相对来说，代码越简洁，越容易读懂而已。

25 楼 weiwangchao 2013-04-16 10:18

明显第一种代码量少，而且可读性还高。第2种就是sb写了来的代码。

24 楼小村长 2013-04-16 09:58

可读性第一。。。。

23 楼 weichao202 2013-04-16 09:57

程序代码其实是主要给人看的，附带着计算机也可以运行。

22 楼 lenzener 2013-04-16 09:16

代码不可能一次编写就永远完美,所以后续的阅读修改是必须的,所以可读性还是放首要,当然,前提是能够运行

21 楼 lincs 2013-04-15 16:28

很明显这个例子举得不合适，这是在代码重构中那本书中提到的写法

20 楼 fuyboy 2013-04-15 16:17

从开发的角度来说可读性还是排第一位的

19 楼 wxq594808632 2013-04-14 22:55

月经贴.

18 楼 shine.xie 2013-04-14 21:02

17 楼 shuihaya 2013-04-14 18:48

可读性很重要，建义都采用规范化就好了。

16 楼 smilerain 2013-04-14 18:19

简洁,清晰并不是矛盾的关系，简洁的代码也可以很清晰，没有人要求你达到最简，
简洁和清晰之间是有度的，如何把握才是关键

15 楼 hyj1254 2013-04-14 16:46

刻意的少只会增加维护难度。

14 楼 a876880345 2013-04-14 11:32

我更倾向于代码多点无所谓，方便扩展，易维护

13 楼 liukai 2013-04-13 22:42

曾经我也追求代码的最少化.
后来才发现,可读性比代码最少化重要太多太多了.

12 楼 minn84 2013-04-13 21:50

公用的代码，少写代码，业务性较强的，多写代码

11 楼 dohkoos 2013-04-13 13:25

代码是一种责任，而不是资产，因此应该减少它的量。你可以通过一个更直接、更朴实的方式来解决问题。

10 楼云上太阳 2013-04-13 10:49

云上太阳写道

这就需要找一个平衡点，平衡点的问题在programmer世界简直太常见了，然而把握这个平衡点的能力也是评价一个coder是否是一个优秀的programmer的参照点之一

就像2楼蜀黍讲的，代码是给人看的，编译是给机器的。如果我们写这段代码是final代码，或者几乎不给人看，那肯定要下大功夫在性能上；反之，就需要好好斟酌下了

发表评论

您还没有登录,请您登录后再发表评论

7顶2踩