如果你热爱编码，就应该少写代码

“如果你喜欢一个人，就应该尽量少说那些甜言蜜语。”不知道大家是否听过某些恋爱专家的肺腑之言。对于程序员来说，如果你热爱编码，那么我也劝你：“能少写一行代码就尽量少写一行。”

可能有些同学觉得这话听起来有点玄乎：“代码写得少，不就意味着缺乏实战经验吗？那我何年何月才能进一线大厂，成为真正的大神呢？”

如果你要这么理解的话，我就必须要纠正你一下。我表达的意思是这样的，来通过两行简短的代码表情达意吧。

if (str == null || "".equals(str)) {}
if (StringUtils.isEmpty()) {}

就上面这两行代码来说，我的第一选择是使用第二行代码来进行判空操作，因为它的代码量更少——简洁明了，也更不容易出错。

如果我们程序员没有这种（写更少代码的）追求的话，那我们的编程技艺就只会原地踏步，长此以往的后果就是各种避免重复造轮子的第三方类库就不会出现。

就判空操作来说，str == null || "".equals(str) 已经干得非常漂亮了（null 和空字符串都考虑在内了），但性能仍然有待优化，可以使用更高效的 str == null || str.length() == 0 来替代。为什么这么说呢？

因为 Sting 类的 equals() 方法本身是很沉重的，其源码如下所示。

public boolean equals(Object anObject) {
    if (this == anObject) {
        return true;
    }
    if (anObject instanceof String) {
        String aString = (String)anObject;
        if (!COMPACT_STRINGS || this.coder == aString.coder) {
            return StringLatin1.equals(value, aString.value);
        }
    }
    return false;
}

而 str.length() == 0 则简单得多，无非就是两个数值“==”比较。孰优孰劣，高下立见。StringUtils.isEmpty() 的内部就恰好使用的是 str == null || str.length() == 0。

对于某些程序员来说，承认这个事实是痛苦的，因为他们是那么的热爱原生。他们争辩说：“那我宁愿使用 str == null || str.length() == 0 也不使用第三方类库的 StringUtils.isEmpty()，因为写原生更直接、更纯粹。”

不，别这样，我耐着性子再劝一句，要理智啊。假如哪天需要把" "（n 个空格）这样的字符串也作为空字符串进行判断呢？难不成要在原生的判断条件中追加 n 个 || " ".equals(str)？

还是追求简洁点好啊！因为我们可以把 StringUtils.isEmpty() 换成 StringUtils.isBlank()，该方法已经为我们考虑好了，来看一下源码。

public static boolean isBlank(final CharSequence cs) {
    int strLen;
    if (cs == null || (strLen = cs.length()) == 0) {
        return true;
    }
    for (int i = 0; i < strLen; i++) {
        if (Character.isWhitespace(cs.charAt(i)) == false) {
            return false;
        }
    }
    return true;
}

很周全吧？

作为程序员，为我们编写的每一行代码负责任是理所应当的一件事。

• 代码简洁度；
• 功能的完整度；
• 执行速度；
• 编码所花费的时间；
• 健壮性；
• 灵活性。

这 6 项指标都值得我们去考量，尽管它们之间有些是对立的，比如说花了一个月的时间实现了一个健壮性非常良好、执行速度也非常快的程序，那可能“编码所花费的时间”（一个月）就有点长了。那怎么样做是值得的呢？

答案只有一个：从简洁开始，再去达其他的标。

代码会随着时间的推移慢慢增加（新的需求、bug 修复），你写的代码越多，bug 藏身的地方就越多，代码编译的速度就会越慢，维护代码的压力也会随之增加。

这是不争的事实。

就好像我们程序员一样，岁月这把杀猪刀不仅会给我们理个发（减少一下发量），还会增加我们的赘肉，如果不坚持锻炼的话，新陈代谢的减缓就会让我们胖成球。

代码是我们程序员创造出来的，如果只在扩展功能的时候追加代码，不在重构的时候精简代码，那么堆叠如山的代码就会像苹果一样腐烂，一个传染俩。

当然了，代码并不是我们的敌人，真正的敌人是谁呢？你往镜子前面一站就恍然大悟了。真正的敌人是我们自己，如果你还热爱编码，就要时刻提醒自己，能少写代码就少写！

记得伟大的文学家马克吐温曾说过这样一句话：

我没有时间写一封简短的信，所以我写了一封长的。

写代码和写文字在本质上是一种事情，把代码写得少一点远比写得多一点更不容易，它需要耗费更多的脑力才能完成。

Medium 上的一个作者 Elliot Chance 也曾表达过和我类似的观点，他说：“要分辨两个程序员的优劣，就是给他们一样的时间，越好的程序员写出来的代码越少（当然是可以运行的）。”

越多的代码并不一定代表着认真，有可能代表的是懒惰，懒得去思考，才会写出臃肿的代码。那怎样才能写出更少的代码呢？

• 首先，要多思考，不要拿到需求就开始敲代码；
• 其次，多积累经验，张三丰打架都是赤手空拳，武器招数都不要不要的，因为他真的是身经百战啊；
• 最后，基础扎实，只有把编程语言的本质吃透，比如说上文中提到的 str.length() == 0 和 "".equals(str)，如果你没有研究过源码，你压根就不知道它们之间的性能优劣。

不过，有一点我需要提醒大家，假如你的公司的绩效考核是按照代码的数量来评定的，那就当我什么皮也没放过。或者，要不你换一家注重代码质量的公司？

好了各位读者朋友们，以上就是本文的全部内容了。能看到这里的都是最优秀的程序员，升职加薪就是你了。如果觉得这篇文章有点用的话，请不要吝啬你们手中点赞的权力。