“如果你喜歡一個人，就應該盡量少說那些甜言蜜語。”不知道大家是否聽過某些戀愛專家的肺腑之言。對于程式員來說，如果你熱愛編碼，那麼我也勸你：“能少寫一行代碼就盡量少寫一行。”
可能有些同學覺得這話聽起來有點玄乎：“代碼寫得少，不就意味着缺乏實戰經驗嗎？那我何年何月才能進一線大廠，成為真正的大神呢？”
如果你要這麼了解的話，我就必須要糾正你一下。我表達的意思是這樣的，來通過兩行簡短的代碼表情達意吧。
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)
不過，有一點我需要提醒大家，假如你的公司的績效考核是按照代碼的數量來評定的，那就當我什麼皮也沒放過。或者，要不你換一家注重代碼品質的公司？
好了各位讀者朋友們，以上就是本文的全部内容了。能看到這裡的都是最優秀的程式員，升職加薪就是你了👍。如果覺得這篇文章有點用的話，請不要吝啬你們手中點贊的權力。
