若是你熱愛編碼，就應該少寫代碼

「若是你喜歡一我的，就應該儘可能少說那些甜言蜜語。」不知道你們是否聽過某些戀愛專家的肺腑之言。對於程序員來講，若是你熱愛編碼，那麼我也勸你：「能少寫一行代碼就儘可能少寫一行。」

可能有些同窗以爲這話聽起來有點玄乎：「代碼寫得少，不就意味着缺少實戰經驗嗎？那我何年何月才能進一線大廠，成爲真正的大神呢？」

若是你要這麼理解的話，我就必需要糾正你一下。我表達的意思是這樣的，來經過兩行簡短的代碼表情達意吧。

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)，若是你沒有研究過源碼，你壓根就不知道它們之間的性能優劣。

不過，有一點我須要提醒你們，假如你的公司的績效考覈是按照代碼的數量來評定的，那就當我什麼皮也沒放過。或者，要不你換一家注重代碼質量的公司？

好了各位讀者朋友們，以上就是本文的所有內容了。能看到這裏的都是最優秀的程序員，升職加薪就是你了👍。若是以爲這篇文章有點用的話，請不要吝嗇大家手中點讚的權力。