Java編程中的一些罕見成績匯總。本站提示廣大學習愛好者：（Java編程中的一些罕見成績匯總）文章只能為提供參考，不一定能成為您想要的結果。以下是Java編程中的一些罕見成績匯總正文
本文羅列了我在四周同事的Java代碼中看到的一些比擬典范的毛病。明顯，靜態代碼剖析（我們團隊用的是qulice）弗成能發明一切的成績，這也是為何我要在這裡列出它們的緣由。
假如你認為少了甚麼，請不惜賜教，我會很願意把它們加上。
上面列出的一切這些毛病根本都與面向對象編程有關，特別是Java的OOP。
類名
讀下這篇短文“甚麼是對象”。類應當是真實生涯中的一個籠統實體，而不是甚麼“validators”，“controller”, “managers”這些器械。假如你的類名以”er”開頭的話——那它就是個蹩腳的設計。
固然了，對象類也是反形式，好比說Apache的StringUtils, FileUtils, 和IOUtils。下面這些都是蹩腳設計的代表。延長浏覽：OOP中對象類的替換計劃。
固然，不要應用前綴或許後綴來辨別類和接口。比喻說，這些名字就是毛病的：IRecord, IfaceEmployee, 或許RecordInterface。平日來講，接口名應當是真實生涯中的實體的名字，類名應當可以解釋它的完成細節。假如這個完成沒有甚麼特殊可解釋的，可以把它叫作Default, Simple或許相似的甚麼。好比說：
class SimpleUser implements User {};
class DefaultRecord implements Record {};
class Suffixed implements Name {};
class Validated implements Content {};
辦法名
辦法可以前往值也能夠前往void。假如辦法前往值的話，它的名字應當能解釋它前往了甚麼，好比說（永久也不要應用get前綴）：
boolean isValid(String name);
String content();
int ageOf(File file);
假如它前往void，那末它的名字應當要解釋它做了甚麼。好比：
void save(File file);
void process(Work work);
void append(File file, String line);
適才提到的這些規矩只要一個破例——JUnit的test辦法不算。上面將會說到這個。
test辦法的名字
在JUnit的測試用例中，辦法名應當是沒有空格的英文語句。用一個例子來講明會更清晰一些：
/**
* HttpRequest can return its content in Unicode.
* @throws Exception If test fails
*/
public void returnsItsContentInUnicode() throws Exception {
}
你的JavaDoc裡的第一句話的開首應當是你要測試的誰人類的名字，然後是一個can。是以，你的第一句話應當是相似於“somebody can do something”。
辦法名也是一樣的，只是沒有主題罷了。假如我在辦法名中央加一個主題的話，我就可以獲得一個完全的句子，正如下面誰人例子中那樣：“HttpRequest returns its content in unicode”。
請留意test辦法的名字是不以can開首的。只要JavaDoc裡的的正文會以can開首。除此以外，辦法名不該該以動詞開首。
理論中最好將測試辦法聲明為拋出Exception的。
變量名
防止組合的變量名，好比說timeOfDay, firstItem，或許httpRequest。類變量及辦法內的變量都是如斯。變量名應當足夠長，防止在它的可見感化域內發生歧義，然則假如可以的話也不要太長。名字應當是雙數或單數情勢的名詞，或許是一個恰當的縮寫。好比：
List<String> names;
void sendThroughProxy(File file, Protocol proto);
private File content;
public HttpRequest request;
有的時刻，假如結構辦法要將入參保留到一個新初始化的對象中的時刻，它的參數和類屬性的名字能夠會抵觸。這類情形，我建議是去失落元音，應用縮寫。
示例：
public class Message {
private String recipient;
public Message(String rcpt) {
this.recipient = rcpt;
}
}
許多時刻，看一下變量的類名就曉得變量該取甚麼名字了。就用它的小寫情勢就行了，像如許就很靠譜：
File file;
User user;
Branch branch;
但是，基本類型的話，永久不要這麼做，好比Integer number或許String string。
假如存在多個分歧性質的變量的話，可以斟酌下應用描述詞。好比：
String contact(String left, String right);
結構辦法
不斟酌異常的話，應當只要一個結構辦法用來將數據存儲到對象變量中。其它結構辦法則應用分歧的參數來挪用這個結構辦法。好比說：
public class Server {
private String address;
public Server(String uri) {
this.address = uri;
}
public Server(URI uri) {
this(uri.toString());
}
}
一次性變量
不管若何都應當防止應用一次性變量。這裡我所說的“一次性“指的是只應用一次的變量。好比上面這個:
String name = "data.txt";
return new File(name);
上述的變量只會應用一次，是以這段代碼可以重組成如許：
return new File("data.txt");
有的時刻，比擬罕有的情形中——重要是為了格局更悅目些——能夠會用到一次性變量。但是，照樣應該盡可能防止這類情形。
異常
無須贅言，永久不要本身吞失落異常，而是應當當它盡可能往上傳遞。公有辦法應當一直把受檢討異常往裡面拋。
不要應用異常來停止流程掌握。比喻說上面這段代碼就是毛病的：
int size;
try {
size = this.fileSize();
} catch (IOException ex) {
size = 0;
}
那假如IOException提醒“磁盤已滿”的話該怎樣辦？你還會以為這個文件年夜小為0，然後持續往下處置？
縮進
關於縮進，重要的規矩就是左括號要末在該行的末尾，要末就在統一行上閉合（關於右括號來講則相反）。好比說，上面這個就不准確，由於第一個左括號沒有在統一行上閉合，而它前面還有其余字符。第二個括號也有成績，由於它後面有字符，但對應的開括號又沒在統一行上：
final File file = new File(directory,
"file.txt");
准確的縮進應當是如許的：
StringUtils.join(
Arrays.asList(
"first line",
"second line",
StringUtils.join(
Arrays.asList("a", "b")
)
),
"separator"
);
關於縮進，第二條主要的規矩就是同時一行中應當盡可能多寫一些——下限是80個字符。下面的誰人例子其實不知足這點，它還可以壓縮一下：
StringUtils.join(
Arrays.asList(
"first line", "second line",
StringUtils.join(Arrays.asList("a", "b"))
),
"separator"
);
過剩的常量
當你願望在類的辦法中同享信息的時刻，應該應用類常量，這些信息應當是你這個類所獨有的。不要把常量看成字符串或數值字面量的替換品來應用——這長短常蹩腳的理論方法，它會對代碼形成淨化。常量（正如OOP中的任何對象一樣）應該在真實世界中有它本身的寄義。看下這些常量在真實生涯中的意思是甚麼：
class Document {
private static final String D_LETTER = "D"; // bad practice
private static final String EXTENSION = ".doc"; // good practice
}
另外一個罕見的毛病就是在單位測試中應用常量來防止測試辦法中湧現冗余的字符串或許數值的字面量。不要這麼做!每一個測試辦法都應當有本身專屬的輸出值。
在每一個新的測試辦法中應用新的文本或許數值。它們是互相自力的。那末為何它們還要同享異樣的輸出常量呢？
測試數據耦合
上面是測試辦法中數據耦合的一個例子：
User user = new User("Jeff");
// maybe some other code here
MatcherAssert.assertThat(user.name(), Matchers.equalTo("Jeff"));
最初一行中，”Jeff”和第一行中的統一個字符串字面值產生了耦合。假如過了幾個月，有人想把第三行這個值換一下，那末他還得花時光找出統一個辦法中哪裡也應用了這個”Jeff”。
為了不這類情形，你最好照樣引入一個變量。
