這段代碼怎麼啦？為什麼有網友表示看到這段代碼，心裡一萬隻羊駝經過？
有的網友覺得，工具包自帶的有，還用寫？寫就寫吧，但是這也寫的太爛了吧！也有的網友表示這段代碼的毛病就是太囉嗦了。還有的網友說是代碼質量差，眼界低。不知道複用已有。 而且方法命名錯誤，根本體現不出這個方法的含義。
同時也有網友表示，看了一遍，你說非常爛吧也沒有，這段代碼最大的性能損耗不在於什麼多定義了一個變量，什麼代碼不優雅，而在於用了equals，各位可以去看看string的這個方法怎麼實現，會多麼的損耗性能，string用的是字符串數組實現的，最好的是直接用length方法，還有說用工具包的，說不定人家就想用這麼一個東西，你讓他去引用一個大包？ 這段代碼只說明寫代碼的人對jdk實現不熟，代碼優雅性上看人了，看過去會彆扭一些，但你說要拿出來噴還不至於，還沒那麼大影響，各位看代碼的時候還是保持客觀的心態去看，不要太偏執。
先不說代碼複用問題，就單這個代碼來說，談效率就是扯淡——這時候要講究的是可讀性，可維護性。工程項目，其實不需要太多奇淫技巧，踏實的代碼風格，挺好的。
if裡面如果只有return boolean的話，就不要用if了，直接return if表達式。上面的例子拋開可以調用jdk的方法不說，可以直接寫成return str!=null&&!"".equals("str")，還有就是方法命名不好，直接isEmpty就好了。
其實，寫Java大多數都是工程化的東西，又不是寫app，一般都會引入一些必要工具包，什麼commonslang啊guava啊slf4j啊lombok什麼的，如果用springboot，基本一個依賴啥都有了，編程本來就枯燥，所以要尋找樂趣，把代碼寫優雅點，帶點藝術細胞，你會發現很開心。
對於這樣一段代碼，大家有什麼想要吐槽的歡迎在下方評論區吐槽交流分享哦！
閱讀更多 戴著面具的旅人 的文章
