沒有語言是完美的。

因語言演化，不同時期不同版本的程序員寫的代碼，在用同一門語言在編程。所以，我們經(jīng)常看到各種不同時期風(fēng)格代碼并存。

新的語言特性都是為提高代碼表達(dá)性，減少犯錯幾率。多用新語言特性寫代碼，絕對沒毛病！

那應(yīng)該如何使用“新”語言特性，讓代碼寫得更好？

Optional

暫不考慮缺乏封裝問題。這段代碼有問題。因為未考慮對象可能為 null。
更好的寫法：

這種寫法很稀缺，所以，新項目總是各種NPE。如果你要問程序員為什么不寫對象為 null 的判斷，答曰：忘了。

空指針的發(fā)明者 Tony Hoare 將其稱為“自己犯下的十億美元錯誤”。

還好Java 8有Optional，它提供了一個對象容器，你需要從中“取出（get）”你所需要對象，但取出前，你需判斷該對象容器中是否真的存在一個對象。

你再不會忘掉判斷對象是否存在，因為你需要從 Optional 取出存在里面的對象。正是這多余的一步，避免你“忘”了。

更簡潔的寫法：

項目中所有可能為 null 的返回值，都要返回 Optional，可大大減少各種意外驚喜。

函數(shù)式編程

準(zhǔn)備參數(shù)的代碼：

• 篩選出審核通過的章節(jié)
• 再把章節(jié)轉(zhuǎn)換成與翻譯引擎通信的格式
• 最后把所有得到的單個參數(shù)打包成一個完整的章節(jié)參數(shù)。

Java8后，不是不需要遍歷集合，而是有了更好的遍歷集合方式。函數(shù)式編程，大部分操作都可歸結(jié)成列表轉(zhuǎn)換，最核心的列表轉(zhuǎn)換就是 map、filter 和 reduce。

大部分循環(huán)語句都是在對一個元素集合進(jìn)行操作，而這些操作基本上都可以用列表操作進(jìn)行替代。

再CR這段代碼，有一循環(huán)語句，這循環(huán)語句在處理的是一個集合中的元素，可用列表轉(zhuǎn)換：

有人可能說這段代碼還不如我原來的循環(huán)語句簡單。兩種寫法根本差異是抽象層次不同，可讀性完全不同：

• 循環(huán)語句是在描述實現(xiàn)細(xì)節(jié)
  必須要做一次“閱讀理解”知曉其中細(xì)節(jié)才能知曉整個場景
• 列表轉(zhuǎn)換的寫法是在描述做什么
  基本上和我們用語言敘述過程對應(yīng)。

其實大多數(shù)人選擇循環(huán)語句只是因為對列表轉(zhuǎn)換不熟練，多寫即可。

為什么我的感覺實踐中，使用這種風(fēng)格，為寫出來的代碼更難理解？
你在列表轉(zhuǎn)換過程中寫了太多代碼！很多人直接在列表轉(zhuǎn)換過程中寫 lambda。lambda 本身相當(dāng)于一個匿名函數(shù)，所以，很多人寫成長函數(shù)了。
lambda 是為了寫短小代碼提供的便利，所以，lambda 中寫出大片代碼，根本就是違反 lambda 設(shè)計初衷的。最好的 lambda 應(yīng)只有一行代碼。

那若一個轉(zhuǎn)換過程中就有很多操作咋辦？

提取出一個函數(shù)！就像 toSectionParameter：完成從 Section 到 SectionParameter 轉(zhuǎn)換。這樣一來，列表轉(zhuǎn)換的本身就完全變成了一個聲明，這樣的寫法才是能發(fā)揮出列表轉(zhuǎn)換價值的寫法。

總結(jié)

代碼風(fēng)格逐步演化，每個程序員對語言的理解程度都有所差異，所以，我們的屎山項目中，各種代碼風(fēng)格并存，各具風(fēng)騷，加重代碼理解難度，這其實就是：不一致的壞味道。

編程風(fēng)之所以格會過時，是因為它存在問題，新風(fēng)格就是用更好方案，注意跟上時代，擁抱變化，多用新特性！

總結(jié)

以上是生活随笔為你收集整理的最好的编程语言是怎样的?的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。