一. 命名

1.1 命名是否具有業(yè)務含義

(1) 命名不精準，用詞寬泛，不能有效反應代碼含義

從溝通的角度看，這就不是一個有效的溝通。要想理解它，需要消耗大量的認知成本，時間和精力,同樣也增加了后來人包括我們自己維護代碼的成本。

其中，Info、data、flag、process、handler、build、maintain、manager、modify等，都是屬于典型的過于寬泛的名字，當這些名字出現(xiàn)的地方，多半都是寫代碼的人當時沒有想好用什么名字。

命名要能夠描述出這段代碼在做的事情，好的名字應該描述意圖，而非細節(jié)。

命名演化示例：

processChapter：處理章節(jié)，命名寬泛

changeChapterToTranlsating：將章節(jié)修改為翻譯中  在描述細節(jié)

startTranslation：開始翻譯，描述意圖

(2) 用技術術語命名

xxxList，xxxMap，xxxSet

這是一種不費腦子的命名方式，因為它是一種基于實現(xiàn)細節(jié)的命名方式。
重要原則：面向接口編程，不要面向?qū)崿F(xiàn)編程。因為接口是穩(wěn)定的，而實現(xiàn)是易變的。

正確示例：

bookList -> books
xxxMap -> xxxMaping

實際上，在實際的代碼中，技術術語的出現(xiàn)，往往代表著缺少了一個應有的模型。

比如在業(yè)務代碼中直接出現(xiàn)了redis，通常來說，我們真正需要的只是一個緩存，而redis只是緩存這個模型的一個實現(xiàn)而已。

而再進一步，緩存這個概念也是一種技術術語，從某種意義上，它也不應該出現(xiàn)在業(yè)務代碼中。Spring就做的比較好，需要緩存，就加上@Cacheable的注解。

注意，在技術類項目中，存在技術術語即是業(yè)務語言的情況；但對于業(yè)務項目，這個說法就必須重新審視。

(3) 用業(yè)務語音寫代碼

編寫可維護的代碼，要使用業(yè)務語音，而怎么知道自己的命名是否用的是業(yè)務語音呢，就是把這個詞講給產(chǎn)品經(jīng)理，看他是否知道。

一個好的做法：在團隊建立自己的業(yè)務語言詞匯表。

approveChapter（long chapterId，long userId）
-> approveChapter（long chapterId，long reviewerId）

(4) 小結(jié)

• 壞味道：不精準的命名，用技術術語命名。
• 解決之道：好的命名要體現(xiàn)代碼在做什么，但無需展示代碼的細節(jié)，更進一步，要準確體現(xiàn)意圖，而不是實現(xiàn)細節(jié)，更高的要求是，用業(yè)務語言寫代碼。
• 原則：描述意圖，而非細節(jié)；面向接口編程，接口是穩(wěn)定的，實現(xiàn)是易變的；命名出現(xiàn)技術名詞，往往是缺少了一個模型；使用業(yè)務語音。

1.2 命名是否符合英語語法

（1）違反語法規(guī)則命名

完成翻譯，方法名：completedTranslate 不是有效的動賓結(jié)構(gòu) ->completeTranslation
重新翻譯，方法名：retranslation 應該是一個動詞 -> retranslate

常見的命名規(guī)則：類名是一個名詞，表示一個對象；方法名是一個動詞，或是動賓短語，表示一個動作。

（2）不準確的英語詞匯

審核：
audit：更官方，偏向?qū)徲?br />review

常用的做法就是把中文詞扔到字典網(wǎng)站從返回的眾多結(jié)果中找到一個自己看著順眼的。好一點的做法是根據(jù)google翻譯，然后根據(jù)二者的英文釋義進行比較。

其實，在這種情況下，最好的解決方案就是建立一個業(yè)務詞匯表，而不是自己臆想。建立詞匯表的一個關鍵點是用集體智慧，而非個體智慧。另外，業(yè)務詞匯表也是屬于構(gòu)建團隊同樣語言的一部分成果。

（3）英語單詞拼寫錯誤

一個好的解決方案，借助工具插件檢查拼寫錯誤。

（4）小結(jié)

• 壞味道：命名違反語法規(guī)則，用詞不準確，單詞拼寫錯誤。更低級的一些，使用拼音，使用不恰當?shù)膯卧~簡寫。（如果非要用縮寫，可以用一些行業(yè)通用的縮寫，而最好不要自己創(chuàng)造，前提是一定要約定好）
• 解決之道：制定代碼規(guī)范，比如類名用名詞，函數(shù)名用動詞或動賓短語；建立團隊詞匯表；經(jīng)常進行代碼評審。
  -小工具：命名插件codelf。

二. 重復代碼

重復代碼產(chǎn)生的一些常見原因：

• 代碼結(jié)構(gòu)不合理導致同一個實現(xiàn)散落各處。由于初期代碼結(jié)構(gòu)設計不合理導致后續(xù)功能實現(xiàn)無法快速找到已有實現(xiàn)，或者找到了但是不好引用已有實現(xiàn)。改進：初期設計代碼邏輯合理，對于不合理的地方要及時重構(gòu) 防止演變成原因2。
• 為了穩(wěn)定性，不動老邏輯，拷貝一份。由于對于業(yè)務的不熟悉和對自己代碼能力的不信任，不敢重構(gòu)導致。改進：通過微重構(gòu)進行多次迭代小改進慢慢優(yōu)化。
• 寫的時候為了快，由于時間緊張或者能力問題，無法識別出的壞代碼。改進：提升能力。

復制粘貼的代碼

結(jié)構(gòu)重復的代碼

示例如下：

@Task
public void sendBook() {
    try {
        this.service.sendBook();
    } catch (Throwable t) {
        this.notification.send(new SendFailure(t)));
        throw t;
    }
}
@Task
public void sendChapter() {
    try {
        this.service.sendChapter();
    } catch (Throwable t) {
        this.notification.send(new SendFailure(t)));
        throw t;
    }
}

優(yōu)化之后：

@Task
public void sendChapter() {
    executeTask(this.service::sendChapter);
}
@Task
public void sendBook() {
    executeTask(this.service::sendBook);
}
private void executeTask(final Runnable runnable) {
    try {
        runnable.run();
    } catch (Throwable t) {
        this.notification.send(new SendFailure(t)));
        throw t;
    }
}

對于支持函數(shù)式編程的程序設計語言來說，可以用語言提供的便利寫法簡化代碼的編寫，就像上面的代碼就是用了 Java 里的方法引用（Method Reference）。

if 和 else 代碼塊中的語句高度類似

只要你看到 if 語句出現(xiàn)，而且 if 和 else 的代碼塊長得又比較像，多半就是出現(xiàn)了這個壞味道。

if (user.isEditor()) {
    service.editChapter(chapterId, title, content, true);
} else {
    service.editChapter(chapterId, title, content, false);
}

優(yōu)化之后：

service.editChapter(chapterId, title, content, user.isEditor());

小結(jié)

• 壞味道：重復的代碼，重復的結(jié)構(gòu)，if 和 else 代碼塊中的語句高度類似
• 解決之道：不要使用復制粘貼；先提取函數(shù)，然后在需要的地方調(diào)用這個函數(shù)。

以上就是java代碼規(guī)范之不合理命名與重復代碼示例詳解的詳細內(nèi)容，更多關于java命名代碼規(guī)范的資料請關注腳本之家其它相關文章！

最新評論