天天看點

Java編碼約定被認為是有害的

在Oracle網站上有Java程式設計語言指南的正式代碼約定 。 您可能希望這份超過20頁的文檔将是有關Java語言的最佳實踐,提示和技巧的最完整,最全面和最權威的來源。 但是一旦你開始閱讀它,失望和憤怒就會增加。 我想指出本指南中最明顯的錯誤,不良做法,不良和過時的建議。 如果您是Java的初學者,隻需不用學習本教程,而是尋找更好,最新的參考資料。 讓恐怖開始吧! 2.2通用檔案名 :

GNUmakefile

生成檔案的首選名稱。 我們使用

gnumake

來建構我們的軟體。

gnumake

建立Java項目? 螞蟻被認為是老派, 行家也被認為是老派。 誰使用

make

來建構WAR,JAR,生成JavaDoc ...? 3.1.1開頭注釋 : 所有源檔案都應以c樣式注釋開頭,該注釋列出了類名稱,版本資訊,日期和版權聲明:将類名稱放入注釋中以開始檔案嗎? 如果我改變主意并稍後重命名課程怎麼辦? 那“ 日期 ”應該代表什麼? 有人使用各種占位符通過版本控制系統自動插入檔案的最後修改時間。 好吧,VCS可以告訴您檔案的建立時間或最後修改時間-一次又一次地修改同一行會使合并變得非常痛苦。 4 –縮進 : 應使用四個空格作為縮進機關。 縮進的确切結構(空格與制表符)未指定。 制表符必須每8個空格(而不是4個)正确設定。 可能是文檔中最違反直覺的部分。 有些人喜歡空格,其他人(包括我)則喜歡制表符。 品味和團隊安排有關。 但是本指南建議同時使用兩者,有時用制表符替換空格。 是“ 未指定 ”。 我的建議:使用頁籤,讓每個開發人員将其IDE配置為具有所需的大小凹痕。

4.1線長

避免使用超過80個字元的行,因為許多終端和工具無法很好地處理它們。

80個字元? 我的筆記本電腦可以輕松容納三倍。 在一行中争取使用120-140個字元,但不要使用硬包裝。 我個人隻是顯示垂直邊距,

右行的長度由可讀性決定。 順便說一句,以下是來自各種庫和架構的類的幾個示例:

  • SQLIntegrityConstraintViolationException

    (JDK

    SQLIntegrityConstraintViolationException

    個字元)
  • AbstractInterruptibleBatchPreparedStatementSetter

    (Spring架構,50個字元)
  • AbstractDataSourceBasedMultiTenantConnectionProviderImpl

    (休眠,56個字元)
  • PreAuthenticatedGrantedAuthoritiesWebAuthenticationDetails

    (Spring Security,58個字元)

而且我們假設整行可以容納80個字元嗎?

5.1.2單行注釋 :

if (condition) {

    /* Handle the condition. */
    ...
}
           

以防萬一代碼不夠自我描述,我建議使用更好的注釋:

if (condition) {

    /* This block is executed if condition == true. */
    ...
}
           

5.1.3尾随評論 :

if (a == 2) {
    return TRUE;            /* special case */
} else {
    return isPrime(a);      /* works only for odd a */
}
           

您的意思是(并且即使沒有評論也不要告訴我它的可讀性較差)?

return a == 2 || isPrime(a);
           

6.1每行編号 :

int level; // indentation level
int size;  // size of table
           

當我們有注釋時,為什麼要使用描述性變量名! 考慮一下這個:

int indentationLevel;
int tableSize;
           

在該部分的後面: 絕對不要在同一行上聲明變量和函數。 例:

long dbaddr, getDbaddr(); // WRONG!
           

當然,這是錯誤的,甚至無法編譯。 我很驚訝沒有提到“ 不要在變量名中放置空格 ”是一種好習慣……

6.3放置 :

僅在塊的開頭放置聲明。 […]不要等到第一次使用變量時才聲明它; 它會使混亂的程式員感到困惑[…]這是編碼約定希望您編寫代碼的方式:

int min;            //inclusive
int max;            //exclusive
int distance;
List<String> list;  //one per each item

min = findMin();
max = findMax();
distance = max - min;
list = new ArrayList<>(distance);
//...
           

這是應如何編寫以避免混淆:

final int minInclusive = findMin();
final int maxExclusive = findMax();
final int distance = maxExclusive - minInclusive;
final List<String> listOfItems = new ArrayList<>(distance);
//...
           

除此之外,我們最終可以(使用nomen est omen )使用

final

關鍵字。 本節後面的代碼示例顯示了類字段缺少

private

修飾符(預設為包私有通路)的情況。 包私人領域?

7.3傳回聲明 :

return (size ? size : defaultSize);
           

也許您沒有注意到,但是從上下文中我們可以看出

size

defaultSize

都是

boolean

類型。 沒錯,

size

defaultSize

可以為

true

false

(!)這是違反直覺的! 從這樣的文檔中,我不僅期望句法正确性,而且期望有意義的代碼和良好實踐! 此外,表達可大大簡化, 一步一步 :

size ? size : defaultSize
size ? true : defaultSize
size || defaultSize
           

7.5聲明 :

空的

for

語句(其中所有工作都在初始化,條件和更新子句中完成)應具有以下形式:

for (initialization; condition; update);
           

'

for

語句 '? 為什麼要使用空的

for

語句? 這是令人困惑的 ,應避免,不應在官方語言指南中予以鼓勵和描述。

獎勵測驗:此代碼在C語言中的用途是什麼?

while(*dst++ = *src++);
           

我相信每個計算機程式員都應該了解上面的代碼片段。 即使您使用Ruby或TSQL進行程式設計。

7.8 switch語句 :

每次遇到

case

(不包括

break

語句)時,請在

break

語句通常所在的位置添加注釋。

我了解意圖,但做法是錯誤的。 不要記錄意外的和容易出錯的代碼片段,而要避免它們。 不要依賴失敗,根本不要使用它。

8.1空行 :

在以下情況下,應始終使用一個空白行:

[…]

  • 在方法的局部變量及其第一條語句之間
  • 在塊[…]或單行[…]注釋之前
  • 一種方法内部的邏輯部分之間,以提高可讀性

看來作者建議使用空行來分隔“ 方法的邏輯部分 ”。 好吧,我稱這些部分為“ 方法 ”。 不要将語句分組在方法内部的塊中,對其進行注釋或彼此分開。 而是将它們提取到單獨的,命名良好的方法中!

在變量聲明和第一個語句之間放置空白行聽起來像是從C語言書中摘錄的。

8.2空格 :

  • 除以外的所有二進制運算符

    .

    應該用空格将其操作數分隔開。 空格絕對不能将一進制運算符(例如一進制減号,增量('

    ++

    ')和減量('

    --

    '))與其操作數分開。 例:

[…]

while (d++ = s++) {
  n++;
}
           

這甚至無法在Java中進行編譯 …

9 –命名約定 (僅PDF版本 ):

char *cp;
           

cp

是Java中

char

指針的一個好名字。 等等, 什麼 ? Java中的

char

指針 ?

10.1提供對執行個體和類變量的通路 :

沒有充分的理由就不要公開任何執行個體或類變量。 真的, 真的是很好的理由! 我曾經使用過

public

場所嗎?

10.4變量指派 :

if (c++ = d++) {        // AVOID! (Java disallows)
    ...
}
           

極好的建議:請避免使用甚至無法在Java中編譯的構造。 這使我們的生活變得更加輕松!

10.5.2傳回值 :

if (booleanExpression) {
    return true;
} else {
    return false;
}
           

應該改為

return booleanExpression;
           

聖牛, 我同意!

摘要

并不是Java程式設計語言的官方代碼約定是完全錯誤的。 它們隻是過時和過時的。 在二十一世紀的第二個十年中,我們擁有了更好的硬體,對代碼品質的更深刻了解以及更現代的智慧資源 。 代碼約定…上一次釋出是在1999年,它們受到C語言的極大啟發,沒有意識到數以百萬計的開發人員尚未編寫的代碼行。 就像設計模式一樣,代碼約定應該随着時間的流逝而出現,而不是明确給出。 是以,請不要再引用或遵循官方指南的建議。

參考: Java 和社群部落格上的JCG合作夥伴 Tomasz Nurkiewicz 認為Java編碼約定有害 。

翻譯自: https://www.javacodegeeks.com/2012/10/java-coding-conventions-considered-harmful.html