“嗨，阿米戈！今天我要告訴你代碼風格和代碼風格的重要性。”
“我將從最重要的事情開始。Java 代碼應該易於閱讀。 代碼的一般方法是：代碼編寫一次，但閱讀一百次。”
“假設您和其他 10 名程序員正在編寫一個應用程序。您在該應用程序上工作了三年，每三個月發布一次中間版本。”
“那麼長？”
“這就是 Java，我的小螞蚱！”一個運行在十幾台服務器上、由 100 個人用 6 年多時間編寫的企業系統怎麼樣？有時也會發生這種情況。”
“哇哦。”
“總之，主要規則，對代碼的主要要求是其他開發人員必須易於閱讀。”
“在其他編程語言中，人們通常以小團隊的形式完成小任務，因此他們可能有另一個主要規則，例如‘它有效嗎？太棒了’。”
“在幾年的時間裡，你的所有團隊成員都會對你編寫的代碼進行多次更改。每次他們都必須了解代碼的工作原理。”
“而且難以理解的完美運行的代碼很難更改。 他們會丟棄它並以自己的方式重寫它。 因此，編寫其他人可以理解的代碼。 如果你可以改進你的代碼，然後改進它。如果它可以改進，那就需要改進了！ ”
“如果你花 15 分鐘編寫代碼，然後花兩個小時改進它，你就做對了。你為團隊節省了多少時間？”
“‘2 小時來理解你的代碼’ x ‘人們需要理解它的 100 次’ = 200 小時。”
“我憑空得出這些數字，但我希望你了解問題及其範圍。 你的代碼是為了讓其他程序員閱讀而創建的。 其他一切都是次要的。”
“代碼運行不正常嗎？我們會修復它。沒有優化？我們會優化它。沒有記錄？我們會添加評論。”
“代碼難讀嗎？把那些廢話扔進垃圾桶，然後從頭開始重新寫一遍！ ”
“我認為這沒什麼大不了的。”
“Java 成為領先的編程語言的原因之一是所有 Java 代碼都是為了供其他程序員閱讀而編寫的。”
“現在讓我們繼續討論第二個問題：如何使代碼盡可能易於閱讀？ ”
“當某人用他或她的母語說出熟悉的單詞時，任何人都能理解。這裡也是如此。當程序員很容易猜到時，代碼很容易閱讀：
A） 每種方法的作用
B) 每節課的目的
C） 每個變量存儲的內容。
所有這些都是通過名稱來傳達的：類名、方法名和變量名。此外，在命名變量時也有風格。還有代碼風格。”
“我準備好傾聽了。”
"編程是基於良好的英語！ 一個寫得很好的程序讀起來就像普通的技術文檔。 "
“讓我們從名字開始吧。 ”
“一個方法名應該簡要描述該方法的作用。然後代碼可以像簡單的散文一樣閱讀。”
public String downloadPhoto(String url)
{
String resultFileName = TempHelper.createTempFileName();
Downloader downloader = new SingleFileDownloader(new Url(url));
downloader.setResultFileName(resultFileName)
downloader.start();
while(downloader.isDone())
{
Thread.sleep(1000);
}
if (downloader.hasError())
return null;
return resultFileName;
}“下面是這樣一個程序的閱讀方式。”
第 1 行。
“該方法稱為‘downloadPhoto’。它似乎是從 Internet 下載照片文件。它下載到哪裡？我們還不知道。從哪裡下載？該方法有一個名為 url 的參數——這可能是用於的 URL下載。”
第 3 行。
“變量 resultFileName 由 TempHelper.createTempFileName() 聲明並賦值；”
所以這必須是我們將保存下載文件的文件的本地路徑。
“'TempHelper'這個名字並沒有告訴我們任何東西。'Helper'後綴說明這是一種實用類，不包含重要的業務邏輯，而是用於簡化經常發生的例行任務。”
“方法名‘createTempFileName’表示該方法創建並返回一個臨時文件（temp file）的名稱。臨時文件是臨時創建的文件，通常在程序關閉時刪除。 “
第 5 行。
“一個 SingleFileDownloader 對像被創建並分配給變量下載器。”
這是將從 Internet 下載文件的對象。
“一個 SingleFileDownloader 對像被分配給變量 downloader。從名稱上，我們可以假設該程序有幾種類型的下載器類。一個是為下載單個文件而編寫的，我們可能會期望在代碼中遇到其他下載器組具有以下名稱的文件：MultiFileDownloader、FileGroupDownloader 或 DirectoryDownloader”
第 6 行。
“我們將下載器對象的 resultFileName 屬性設置為變量 resultFileName 的值。換句話說，我們告訴加載器在哪裡保存下載的文件。正如您所期望的那樣。所以，我們基本上是在預測代碼！”
第 7 行。
“我們調用 start 方法。下載開始。這是有道理的。我想知道下載是如何發生的：部分地，在一個單獨的線程上，或者整個事情就在這裡？如果我們在這裡下載整個事情，它可能需要一個時間長了會產生後果。”
第 8-11 行。
“啊。這裡我們看到有人在等待下載完成時編寫的標準循環。downloder 對像有一個 done 屬性，它由 isDone() 方法返回。因為該方法調用的是 isDone()，而不是 getDone( )，我們得出結論，done 變量是一個布爾值，或者可能是一個布爾值。”
第 13-14 行。
“如果在下載過程中發生錯誤，那麼 downloadPhoto 方法將返回 null。它處理錯誤是好的。它只返回 null 是不好的——不清楚錯誤是什麼。最好拋出一個異常，並提供有關的信息錯誤。”
第 16 行。
“我們返回包含下載文件的本地文件的路徑。”
“哇！”
“這個程序的代碼非常清楚它做了什麼。你甚至可以猜測這個程序是如何組織的以及我們會找到哪些其他類/方法。”
“現在我明白名字的重要性了。”
“關於名稱的更多信息。您通常可以猜到一個對象/類有哪些方法。例如，如果一個對像是一個集合，那麼它很可能有一個 size() 或 count() 方法來獲取元素的數量。還有，它可能會有一個 add() 或 insert() 方法。使用 get/getItem/getElement 方法從集合類中檢索元素。”
“如果一個變量被稱為 i、j 或 k，那麼它很可能是一個循環計數器。”
“如果一個變量被稱為 m 或 n，那麼它很可能是一個數組/集合的大小。”
“如果一個變量名為 name，那麼它很可能是一個包含某人姓名的字符串。”
“如果一個類稱為 FileInputStream，那麼它同時是一個文件和一個輸入流。”
“你看到的代碼越多，就越容易閱讀別人的代碼。”
“但有時有些代碼很難閱讀。在這種情況下，這裡有一個非常實用的建議：”
| 提示 |
|---|
| 編寫代碼就好像它會由一個知道你住在哪裡的暴力精神病患者維護一樣。 |
“這很有趣，但同時也不好笑。”
“現在談談用於命名變量的樣式。”
“Java 開發人員試圖為變量和方法提供信息豐富的名稱。結果，名稱通常由幾個單詞組成。複合名稱的大寫有 4 種樣式。”
1) 小寫字母 ——所有單詞都用小寫字母書寫。例如：
“溫室” 變“溫室”
“好萊塢女孩” 變成了 “好萊塢女孩”
此樣式用於包名稱。
2) 大寫 ——所有單詞都用大寫字母書寫，並用下劃線分隔。例如：
“最大值” 變為MAX_VALUE
“貓數” 變為CAT_COUNT
“此樣式用於常量名稱（最終靜態字段）。”
3) CamelCase—— 所有單詞都用小寫字母書寫，除了每個單詞的第一個字母是大寫的。例如：
“溫室” 變成 “溫室”
“好萊塢女孩” 變成了“好萊塢女孩”
這種風格用於類和接口的名稱。
4) Lower CamelCase (mixed case) – 所有的單詞都是用小寫字母寫的，除了第一個單詞的第一個字母是大寫的。例如：
“獲取寬度”變為“getWidth”
“獲取好萊塢女孩的名字”變為 “getHollywoodGirlName”
“這種風格用於變量和方法的名稱。”
“所以，沒有太多的規則。”
1) 一切都是用 Lower CamelCase 寫的。
2) 類名和接口名總是大寫。
3) 包名總是小寫。
4) 常量總是大寫的。
“有一些細微差別，但總的來說就是這樣。”
“現在關於方法。 ”方法名稱幾乎總是以動詞開頭！'count' 是一個不好的方法名稱。最好將其稱為 getCount()。一種方法對對象執行某些操作： startDownload、interrupt 、sleep 、loadPirateMusic。”
“如您所知，有用於處理對象屬性/字段的 getter 和 setter： getName / setName、getCount / setCount等。”
“唯一的例外是布爾值。對於布爾值，getter 名稱使用'is'，而不是'get'，例如isDone，isEmpty。這樣它更接近於普通語音。”
“每天工作 2 小時而不是 8 小時怎麼樣？受到誘惑嗎？”
“是的！”
“正如你應該的那樣。對於初級 Java 開發人員來說，基本要求是對 Java 的基礎知識，即 Java Core 有很好的理解。”
“我還有一個問題。為什麼我們有這些不同的方法來獲取元素的數量？”
| 班級 | 獲取元素數量的方法/屬性 |
|---|---|
| 細繩 | 長度() |
| 大批 | 長度 |
| 數組列表 | 大小() |
| 線程組 | 活躍計數() |
“首先，Java 是 20 多年前發明的，在setCount / getCount之類的要求尚未建立之前，有一種從 C 語言中提取的通用方法，即‘使其盡可能短’。”
“其次，語義在這裡發揮作用。當談論數組時，我們談論它的長度。當談論集合時，我們談論它的大小。”
“多麼有趣的一課啊。”
“我還想告訴你更多，但我怕你一下子記不起來，還是分小份分給你吃比較好。”
“但我確實想談談有關使用大括號的風格：{}。有兩種方法：”
1） 括號每次都換行
2) 左括號在上一行的末尾，而右括號在新的一行。這種樣式稱為“埃及牙套”。
“老實說，你可以選擇如何編碼。很多人在同一行使用左大括號。很多人把它放在新的一行。這就像關於打破雞蛋哪一端的爭論：小端還是大端結尾。”
“我唯一可以推薦的是堅持你正在從事的項目中使用的任何風格。不要改變別人的代碼來匹配你喜歡的風格。 人是不完美的。我以 Bilaabo 博士的身份告訴你這一點。 “
“感謝有趣的課程，Bilaabo。我會去反思你所說的話。”
GO TO FULL VERSION