其他分享
首页 > 其他分享> > 如果你热爱编码,就应该少写代码

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

作者:互联网

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

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

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

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 也曾表达过和我类似的观点,他说:“要分辨两个程序员的优劣,就是给他们一样的时间,越好的程序员写出来的代码越少(当然是可以运行的)。”

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

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

 

 

标签:编码,return,少写,代码,equals,程序员,热爱,str,null
来源: https://blog.51cto.com/u_2324584/3035918