Bahan ini mengandungi ralat paling tipikal yang saya lihat dalam kod Java orang yang bekerja dengan saya. Analisis statik (kami menggunakan qulice ), atas sebab yang jelas, tidak dapat mengesan semua ralat tersebut, itulah sebabnya saya memutuskan untuk menyenaraikannya di sini. Semua ralat ini berkaitan dengan pengaturcaraan berorientasikan objek secara umum dan Java khususnya.
Nama Kelas
Kelas anda mestilah abstraksi objek kehidupan sebenar tanpa "
pengesah " , " pengawal
" ,
" pengurus
" , dsb. Jika nama kelas anda berakhir dengan "-er" ia adalah reka bentuk yang buruk. Dan sudah tentu, kelas penolong anti-corak seperti Apache's
StringUtils ,
FileUtils , dan
IOUtils ialah contoh hebat corak reka bentuk yang dahsyat. Jangan sekali-kali menambah akhiran atau awalan untuk membezakan antara antara muka dan kelas. Sebagai contoh, semua nama ini mengerikan:
IRecord ,
IfaceEmployee atau
RecordInterface . Biasanya, nama antara muka ialah nama objek kehidupan sebenar, manakala nama kelas harus menerangkan butiran pelaksanaan. Jika tiada yang khusus boleh dikatakan tentang pelaksanaan, nama "
Lalai ", "
Mudah ", atau sesuatu yang serupa akan dilakukan. Sebagai contoh:
class SimpleUser implements User {}; class DefaultRecord implements Record {}; class Suffixed implements Name {}; class Validated implements Content {};
Nama Kaedah
Kaedah boleh sama ada mengembalikan "
sesuatu " atau mengembalikan "
batal ". Jika kaedah mengembalikan sesuatu, maka namanya harus menjelaskan apa yang akan dikembalikan. Contohnya (jangan gunakan awalan "
get "):
boolean isValid(String name); String content(); int ageOf(File file); Jika "
void " dikembalikan, nama itu harus menjelaskan apa yang dilakukan oleh kaedah tersebut. Sebagai contoh:
void save(File file); void process(Work work); void append(File file, String line); Terdapat hanya satu pengecualian kepada peraturan ini - kaedah ujian
JUnit . Mereka diterangkan di bawah.
Nama Kaedah Ujian
Nama kaedah dalam ujian JUnit mesti dibina sebagai ayat bahasa Inggeris tanpa ruang. Ini lebih mudah untuk dijelaskan dengan contoh: Adalah
/** * HttpRequest can return its content in Unicode. * @throws Exception If test fails */ public void returnsItsContentInUnicode() throws Exception { } penting untuk memulakan ayat pertama JavaDoc anda dengan nama kelas yang anda uji diikuti dengan "
boleh ". Jadi, ayat pertama hendaklah sentiasa seperti frasa "
seseorang boleh melakukan sesuatu ." Nama kaedah akan menyatakan perkara yang sama, tetapi tanpa subjek ujian. Jika saya menambahkannya pada permulaan nama kaedah, saya mendapat ayat bahasa Inggeris yang lengkap, seperti dalam contoh di atas: "
HttpRequest mengembalikan kandungannya dalam unicode ." Sila ambil perhatian bahawa nama kaedah ujian tidak bermula dengan "
boleh ". Hanya ulasan JavaDoc bermula dengan "
boleh ". Di samping itu, nama kaedah tidak sepatutnya bermula dengan kata kerja (
Daripada penterjemah: nampaknya, pengarang bermaksud mood imperatif kata kerja itu ). Adalah amalan yang baik untuk menunjukkan bahawa pengecualian dilemparkan apabila mengisytiharkan kaedah ujian.
Nama Pembolehubah
Elakkan nama pembolehubah kompaun seperti
timeOfDay ,
firstItem , atau
httpRequest . Saya maksudkan kedua-dua pembolehubah kelas dan pembolehubah kaedah. Nama pembolehubah hendaklah cukup panjang untuk mengelakkan kekaburan dalam skopnya, tetapi tidak terlalu panjang jika boleh. Nama mestilah kata nama tunggal atau jamak. Contohnya: Kadangkala mungkin terdapat perlanggaran antara parameter pembina dan medan kelas jika pembina menyimpan data input ke dalam objek yang dicipta. Dalam kes ini, saya mengesyorkan membuat singkatan dengan mengalih keluar vokal. Contoh: Dalam kebanyakan kes, nama pembolehubah terbaik ialah nama kelas yang sepadan. Hanya gunakan huruf besar dan anda akan baik-baik saja: Walau bagaimanapun, jangan sekali-kali melakukan perkara yang sama untuk jenis primitif seperti atau . Anda juga boleh menggunakan kata sifat apabila terdapat beberapa pembolehubah dengan ciri yang berbeza. Sebagai contoh:
List
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 numberString stringString contact(String left, String right);
Pembina
Tanpa pengecualian, hanya ada satu pembina yang menyimpan data ke dalam pembolehubah objek. Semua pembina lain mesti memanggil yang ini dengan parameter yang berbeza:
public class Server { private String address; public Server(String uri) { this.address = uri; } public Server(URI uri) { this(uri.toString()); } }
Pembolehubah Sekali
Elakkan pembolehubah sekali sahaja pada semua kos. Dengan "boleh guna" saya maksudkan pembolehubah yang digunakan sekali. Seperti dalam contoh ini:
String name = "data.txt"; return new File(name); Pembolehubah digunakan sekali sahaja dan kod itu boleh dipermudahkan kepada:
return new File("data.txt"); Kadangkala, dalam kes yang sangat jarang berlaku - kebanyakannya disebabkan pemformatan yang lebih baik - pembolehubah satu kali boleh digunakan. Walau bagaimanapun, cuba elakkan situasi sedemikian.
Pengecualian.
Sudah tentu, anda tidak boleh "menelan" pengecualian; mereka harus dilemparkan setinggi mungkin. Pengecualian daripada kaedah persendirian mesti dikendalikan secara luaran. Jangan sekali-kali menggunakan pengecualian untuk mengawal aliran. Kod dalam contoh adalah tidak betul:
int size; try { size = this.fileSize(); } catch (IOException ex) { size = 0; } Secara serius, bagaimana jika IOException mengatakan "cakera penuh", adakah anda akan menganggap saiz fail adalah sifar dan meneruskan?
Lekukan.
Untuk lekukan, peraturan umum ialah kurungan mesti sama ada menamatkan baris atau menutup pada baris yang sama (peraturan yang bertentangan digunakan untuk kurungan penutup). Dalam contoh di bawah, kod tersebut tidak betul kerana kurungan pertama tidak ditutup pada baris yang sama dan terdapat aksara selepasnya. Kurungan kedua mempunyai masalah yang sama kerana terdapat aksara sebelum itu, dan tiada kurungan pembukaan pada baris semasa.
final File file = new File(directory, "file.txt"); Lekukan yang betul sepatutnya kelihatan seperti ini:
StringUtils.join( Arrays.asList( "first line", "second line", StringUtils.join( Arrays.asList("a", "b") ) ), "separator" ); Peraturan penting kedua lekukan ialah anda harus meletakkan sebanyak mungkin pada satu baris - dalam 80 aksara. Contoh di atas tidak sah kerana ia boleh dimampatkan:
StringUtils.join( Arrays.asList( "first line", "second line", StringUtils.join(Arrays.asList("a", "b")) ), "separator" );
Pemalar Berlebihan.
Pemalar kelas harus digunakan apabila anda ingin berkongsi akses kepada maklumat antara kaedah kelas, dan maklumat ini adalah ciri(
! ) kelas anda. Jangan gunakan pemalar sebagai pengganti rentetan atau literal angka - amalan yang sangat buruk, ia membawa kepada pencemaran kod. Pemalar (seperti objek OOP lain) mesti mempunyai makna dalam dunia sebenar. Apakah maksud pemalar ini dalam dunia nyata:
class Document { private static final String D_LETTER = "D"; // bad practice private static final String EXTENSION = ".doc"; // good practice } Satu lagi kesilapan biasa ialah menggunakan pemalar dalam ujian unit untuk mengelakkan penduaan rentetan/huruf angka dalam kaedah ujian. Jangan buat begitu! Setiap kaedah ujian mesti beroperasi pada set nilai inputnya sendiri. Gunakan teks dan nombor baharu dalam setiap kaedah ujian baharu. Ujian adalah bebas. Jadi mengapa mereka harus berkongsi pemalar input yang sama?
Gandingan Data Ujian.
Berikut adalah contoh cangkuk dalam kaedah ujian:
User user = new User("Jeff"); // maybe some other code here MatcherAssert.assertThat(user.name(), Matchers.equalTo("Jeff")); Dalam baris terakhir, kami menggabungkan "
Jeff " dengan literal rentetan yang sama yang dinyatakan dalam baris pertama. Jika, beberapa bulan kemudian, seseorang ingin menukar nilai dalam baris ketiga, dia perlu menghabiskan masa tambahan mencari di mana lagi "
Jeff " digunakan dalam kaedah ini. Untuk mengelakkan data terselit ini, anda harus memperkenalkan pembolehubah.
GO TO FULL VERSION