我在 Eclipse 中使用 Checkstyle (Google Checks)，對于每個 Javadoc 標簽，編譯器都會顯示警告“Javadoc 標簽前面應該有一個空行”，即使有一個。消除警告的唯一方法是引入 HTML 換行符。
例如：
/**
* shows drinks units in fridge.
*
* @return amount of drinks in fridge.
*/
編譯器將給出警告“Javadoc 標記‘@return’應以空行開頭”。
當然可以在 Checkstyle 中停用警告，但是我仍然想知道編譯器為什么會這樣做。即使沒有換行符，我的老師和同學也沒有這個警告，他們不知道我為什么會有這個警告，在 Checkstyle 的 sourceforge 頁面上（https://checkstyle.sourceforge.io/apidocs/com/puppycrawl/ tools/checkstyle/checks/javadoc/RequireEmptyLineBeforeBlockTagGroupCheck.html ) ，也不需要 HTML balise。
謝謝你的幫助 ！
uj5u.com熱心網友回復：
檢查該位置的確切位元組。上面可能有一個實際的角色，比如一個不間斷的空格；文字處理器通常會“花哨”你的輸入并將它們變成奇怪的字符。例如，如果您將“hello”粘貼到 word 中，然后再粘貼回 java，則它不再是字串常量，因為 word 決定將它們轉換為花括號：“hello”，這不是 java。可以使用相同的策略在那里偷偷地插入不間斷的空間等。絕大多數空白 unicode 字符都算作空格，但 checkstyle 插件在這方面可能會被破壞（它只會認為空格和制表符無關緊要）。或者，checkstyle 可能需要在空行的 * 后面有一個空格，以便該行上的完整字符集是\t * (tab, space, star,
但最重要的是...
你的行程壞了。您有一個樣式檢查器，現在專注于完全不相關的內容，但是您的 javadoc 很糟糕。
您有一個可能名為 的方法countDrinksInFridge()，并且您使用 javadoc“記錄”了此方法，該方法為您提供了完全無用的非資訊，并且執行了兩次以啟動！DRY是編程中幾乎普遍認同的絕妙原則是有原因的，而您只是違反了它。兩次，不少。
樣式檢查器抱怨您使用了哪種確切的空格字符，但認為撰寫笨拙的 javadoc 非常好，這一事實足以證明它顯然沒有做它應該做的事情。
良好的檔案規則如下。它們都基于一個簡單的想法：檔案應該被維護，維護不是免費的，而且檔案很難甚至不可能測驗，所以它們中的任何錯誤往往會在人們意識到它是錯誤的之前徘徊很長時間。就像撰寫代碼一樣，如果您不必要地用 10 行代碼來撰寫本可以在 2 行中同樣高效地完成的代碼，那么您就搞砸了。這同樣適用于檔案。不要重復自己，不要提供無意義或多余的資訊。說清楚，說得簡潔。
如果因為方法名稱準確地描述了方法的全部性質而沒有更多要添加的內容，則不要記錄它。方法名稱是檔案。讓它自立。
如果您確實有要添加的內容，但描述它回傳的內容完全涵蓋了它，那么只需撰寫
@return標簽即可。這可以：
/**
* @return amount of drinks in the fridge.
*/
public int countDrinks() { ... ... }
你在這里有 javadoc 的唯一原因是因為有人認為提到“在冰箱里”是值得的。當然，這仍然是糟糕的代碼風格：
class Fridge {
/**
* @return The amount of drinks in the fridge.
*/
public int countDrinks() { ...... }
}
這很糟糕，因為“在冰箱里”在這里不是有用的資訊。呃，當然在冰箱里。它在一個名為Fridge. 想想吧：給我一個程式員是迷茫的什么勝算Fridge的countDrinks方法做，但javadoc的@return The amount of drinks in the fridge.清除一切，為他們。當然，這些幾率是 0%，而且還沒有四舍五入。
教訓是：防止不良代碼風格、難以維護的代碼以及其他類似風格指南相關的想法的流程是您無法僅使用軟體和規則包來修復的。這是人類的事情：您從事團隊內培訓、招聘實踐、代碼審查流程，以及一種普遍的文化，即人們應該關心代碼的客觀質量，而不是沉迷于過度強制的衡量標準，例如“代碼庫是否通過”一些風格檢查規則集？'，只有在你建立了所有這些之后，你才能考慮使用一些軟體來輕松幫助你完成團隊的需求。
轉載請註明出處，本文鏈接：https://www.uj5u.com/yidong/324398.html