“如果你喜歡一個人，就應該儘量少說那些甜言蜜語。”不知道大家是否聽過某些戀愛專家的肺腑之言。對於程序員來說，如果你熱愛編碼，那麼我也勸你：“能少寫一行代碼就儘量少寫一行。”
可能有些同學覺得這話聽起來有點玄乎：“代碼寫得少，不就意味著缺乏實戰經驗嗎？那我何年何月才能進一線大廠，成為真正的大神呢？”
如果你要這麼理解的話，我就必須要糾正你一下。我表達的意思是這樣的，來通過兩行簡短的代碼表情達意吧。
<code>if(str==null||"".equals(str)){}
if(StringUtils.isEmpty()){}
/<code>就上面這兩行代碼來說，我的第一選擇是使用第二行代碼來進行判空操作，因為它的代碼量更少——簡潔明瞭，也更不容易出錯。
如果我們程序員沒有這種（寫更少代碼的）追求的話，那我們的編程技藝就只會原地踏步，長此以往的後果就是各種避免重複造輪子的第三方類庫就不會出現。
就判空操作來說，str == null || "".equals(str) 已經幹得非常漂亮了（null 和空字符串都考慮在內了），但性能仍然有待優化，可以使用更高效的 str == null || str.length() == 0 來替代。為什麼這麼說呢？
因為 Sting 類的 equals() 方法本身是很沉重的，其源碼如下所示。
<code>publicbooleanequals(ObjectanObject){
if(this==anObject){
returntrue;
}
if(anObjectinstanceofString){
StringaString=(String)anObject;
if(!COMPACT_STRINGS||this.coder==aString.coder){
returnStringLatin1.equals(value,aString.value);
}
}
returnfalse;
}
/<code>而 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()，該方法已經為我們考慮好了，來看一下源碼。
<code>publicstaticbooleanisBlank(finalCharSequencecs){
intstrLen;
if(cs==null||(strLen=cs.length())==0){
returntrue;
}
for(inti=0;i<strlen>if(Character.isWhitespace(cs.charAt(i))==false){
returnfalse;
}
}
returntrue;
}
/<strlen>/<code>很周全吧？
作為程序員，為我們編寫的每一行代碼負責任是理所應當的一件事。
- 代碼簡潔度；
- 功能的完整度；
- 執行速度；
- 編碼所花費的時間；
- 健壯性；
- 靈活性。
這 6 項指標都值得我們去考量，儘管它們之間有些是對立的，比如說花了一個月的時間實現了一個健壯性非常良好、執行速度也非常快的程序，那可能“編碼所花費的時間”（一個月）就有點長了。那怎麼樣做是值得的呢？
答案只有一個：從簡潔開始，再去達其他的標。
代碼會隨著時間的推移慢慢增加（新的需求、bug 修復），你寫的代碼越多，bug 藏身的地方就越多，代碼編譯的速度就會越慢，維護代碼的壓力也會隨之增加。
這是不爭的事實。
就好像我們程序員一樣，歲月這把殺豬刀不僅會給我們理個髮（減少一下發量），還會增加我們的贅肉，如果不堅持鍛鍊的話，新陳代謝的減緩就會讓我們胖成球。
代碼是我們程序員創造出來的，如果只在擴展功能的時候追加代碼，不在重構的時候精簡代碼，那麼堆疊如山的代碼就會像蘋果一樣腐爛，一個傳染倆。
當然了，代碼並不是我們的敵人，真正的敵人是誰呢？你往鏡子前面一站就恍然大悟了。真正的敵人是我們自己，如果你還熱愛編碼，就要時刻提醒自己，能少寫代碼就少寫！
記得偉大的文學家馬克吐溫曾說過這樣一句話：
我沒有時間寫一封簡短的信，所以我寫了一封長的。
寫代碼和寫文字在本質上是一種事情，把代碼寫得少一點遠比寫得多一點更不容易，它需要耗費更多的腦力才能完成。
Medium 上的一個作者 Elliot Chance 也曾表達過和我類似的觀點，他說：“要分辨兩個程序員的優劣，就是給他們一樣的時間，越好的程序員寫出來的代碼越少（當然是可以運行的）。”
越多的代碼並不一定代表著認真，有可能代表的是懶惰，懶得去思考，才會寫出臃腫的代碼。那怎樣才能寫出更少的代碼呢？
- 首先，要多思考，不要拿到需求就開始敲代碼；
- 其次，多積累經驗，張三丰打架都是赤手空拳，武器招數都不要不要的，因為他真的是身經百戰啊；
- 最後，基礎紮實，只有把編程語言的本質吃透，比如說上文中提到的 str.length() == 0 和 "".equals(str)，如果你沒有研究過源碼，你壓根就不知道它們之間的性能優劣。
不過，有一點我需要提醒大家，假如你的公司的績效考核是按照代碼的數量來評定的，那就當我什麼皮也沒放過。或者，要不你換一家注重代碼質量的公司？
閱讀更多 Java的小本家 的文章
