Kesalahan umum dalam kode Java.

Materi ini berisi kesalahan paling umum yang pernah saya lihat dalam kode Java orang yang bekerja dengan saya. Analisis statis (kami menggunakan qulice ), karena alasan yang jelas, tidak dapat mendeteksi semua kesalahan tersebut, itulah sebabnya saya memutuskan untuk mencantumkannya di sini. Semua kesalahan ini terkait dengan pemrograman berorientasi objek pada umumnya dan Java pada khususnya.

Nama Kelas

Kelas Anda harus berupa abstraksi objek kehidupan nyata tanpa " validator " , " pengontrol " , " manajer " , dll. Jika nama kelas Anda diakhiri dengan "-er" itu desain yang buruk. Dan tentu saja, kelas pembantu anti-pola seperti StringUtils , FileUtils , dan IOUtils dari Apache adalah contoh bagus dari pola desain yang buruk. Jangan pernah menambahkan sufiks atau awalan untuk membedakan antara antarmuka dan kelas. Misalnya, semua nama ini jelek: IRecord , IfaceEmployee , atau RecordInterface . Biasanya, nama antarmuka adalah nama objek kehidupan nyata, sedangkan nama kelas harus menjelaskan detail implementasi. Jika tidak ada hal spesifik yang dapat dikatakan tentang implementasinya, nama " Default ", " Simple ", atau yang serupa sudah cukup. Misalnya: class SimpleUser implements User {}; class DefaultRecord implements Record {}; class Suffixed implements Name {}; class Validated implements Content {};

Nama Metode

Metode dapat mengembalikan " sesuatu " atau mengembalikan " kekosongan ". Jika suatu metode mengembalikan sesuatu, maka namanya harus menjelaskan apa yang akan dikembalikan. Misalnya (jangan gunakan awalan " get "): boolean isValid(String name); String content(); int ageOf(File file); Jika " void " dikembalikan, namanya harus memperjelas fungsi metode tersebut. Misalnya: void save(File file); void process(Work work); void append(File file, String line); Hanya ada satu pengecualian untuk aturan ini - metode pengujian JUnit . Hal tersebut dijelaskan di bawah ini.

Nama Metode Tes

Nama metode dalam pengujian JUnit harus dibuat sebagai kalimat bahasa Inggris tanpa spasi. Hal ini lebih mudah untuk dijelaskan dengan sebuah contoh: Penting /** * HttpRequest can return its content in Unicode. * @throws Exception If test fails */ public void returnsItsContentInUnicode() throws Exception { } untuk memulai kalimat pertama JavaDoc Anda dengan nama kelas yang Anda uji diikuti dengan “ can ”. Jadi, kalimat pertama harus selalu seperti kalimat " seseorang bisa melakukan sesuatu ". Nama metode akan menyatakan hal yang sama, tetapi tanpa subjek pengujian. Jika saya menambahkannya ke awal nama metode, saya mendapatkan kalimat bahasa Inggris lengkap, seperti pada contoh di atas: “ HttpRequest return its content in unicode .” Harap dicatat bahwa nama metode pengujian tidak dimulai dengan “ can ”. Hanya komentar JavaDoc yang dimulai dengan " can ". Selain itu, nama metode tidak boleh diawali dengan kata kerja ( Dari penerjemah: rupanya yang dimaksud penulis adalah mood imperatif dari kata kerja tersebut ). Merupakan praktik yang baik untuk menunjukkan bahwa pengecualian diberikan saat mendeklarasikan metode pengujian.

Nama Variabel

Hindari nama variabel gabungan seperti timeOfDay , firstItem , atau httpRequest . Maksud saya variabel kelas dan variabel metode. Nama variabel harus cukup panjang untuk menghindari ambiguitas dalam cakupannya, namun jangan terlalu panjang jika memungkinkan. Nama harus berupa kata benda tunggal atau jamak. Misalnya: Terkadang mungkin terjadi tabrakan antara parameter konstruktor dan bidang kelas jika konstruktor menyimpan data masukan ke dalam objek yang dibuat. Dalam hal ini, saya sarankan membuat singkatan dengan menghilangkan huruf vokal. Contoh: Dalam kebanyakan kasus, nama variabel terbaik adalah nama kelas yang bersangkutan. Cukup gunakan huruf besar dan Anda akan baik-baik saja: Namun, jangan pernah melakukan hal yang sama untuk tipe primitif seperti atau . Anda juga dapat menggunakan kata sifat ketika terdapat beberapa variabel dengan karakteristik berbeda. Misalnya: 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 number String string String contact(String left, String right);

Konstruktor

Tanpa pengecualian, hanya boleh ada satu konstruktor yang menyimpan data ke dalam variabel objek. Semua konstruktor lain harus memanggil konstruktor ini dengan parameter berbeda: public class Server { private String address; public Server(String uri) { this.address = uri; } public Server(URI uri) { this(uri.toString()); } }

Variabel Satu Kali

Hindari variabel satu kali dengan cara apa pun. Yang saya maksud dengan “sekali pakai” adalah variabel yang digunakan satu kali. Seperti dalam contoh ini: String name = "data.txt"; return new File(name); Sebuah variabel digunakan hanya sekali, dan kodenya dapat disederhanakan menjadi: return new File("data.txt"); Kadang-kadang, dalam kasus yang sangat jarang terjadi - sebagian besar karena format yang lebih baik - variabel satu kali dapat digunakan. Namun, cobalah untuk menghindari situasi seperti itu.

Pengecualian.

Tentu saja, Anda tidak boleh "menelan" pengecualian; pengecualian tersebut harus dibuang setinggi mungkin. Pengecualian dari metode privat harus ditangani secara eksternal. Jangan pernah menggunakan pengecualian untuk mengontrol aliran. Kode dalam contoh salah: int size; try { size = this.fileSize(); } catch (IOException ex) { size = 0; } Serius, bagaimana jika IOException mengatakan "disk penuh", apakah Anda akan menganggap ukuran file nol dan melanjutkan?

Lekukan.

Untuk lekukan, aturan umumnya adalah tanda kurung harus mengakhiri baris atau menutup pada baris yang sama (aturan sebaliknya berlaku untuk tanda kurung penutup). Pada contoh di bawah, kodenya salah karena tanda kurung pertama tidak ditutup pada baris yang sama dan terdapat karakter setelahnya. Braket kedua mempunyai masalah yang sama karena ada karakter sebelumnya, dan tidak ada braket pembuka pada baris saat ini. final File file = new File(directory, "file.txt"); Indentasi yang benar akan terlihat seperti ini: StringUtils.join( Arrays.asList( "first line", "second line", StringUtils.join( Arrays.asList("a", "b") ) ), "separator" ); Aturan penting kedua dari indentasi adalah Anda harus menempatkan sebanyak mungkin pada satu baris - dalam 80 karakter. Contoh di atas tidak valid karena dapat dikompresi: StringUtils.join( Arrays.asList( "first line", "second line", StringUtils.join(Arrays.asList("a", "b")) ), "separator" );

Konstanta Berlebihan.

Konstanta kelas harus digunakan ketika Anda ingin berbagi akses informasi antar metode kelas, dan informasi ini merupakan karakteristik( ! ) kelas Anda. Jangan gunakan konstanta sebagai pengganti string atau literal numerik - praktik yang sangat buruk, ini menyebabkan polusi kode. Konstanta (seperti objek OOP lainnya) harus mempunyai makna di dunia nyata. Apa arti dari konstanta ini di dunia nyata: class Document { private static final String D_LETTER = "D"; // bad practice private static final String EXTENSION = ".doc"; // good practice } Kesalahan umum lainnya adalah menggunakan konstanta dalam pengujian unit untuk menghindari duplikasi string/literal numerik dalam metode pengujian. Jangan lakukan itu! Setiap metode pengujian harus beroperasi pada kumpulan nilai masukannya sendiri. Gunakan teks dan angka baru di setiap metode tes baru. Tesnya independen. Jadi mengapa mereka harus berbagi konstanta masukan yang sama?

Uji Kopling Data.

Berikut adalah contoh hooking dalam metode pengujian: User user = new User("Jeff"); // maybe some other code here MatcherAssert.assertThat(user.name(), Matchers.equalTo("Jeff")); Di baris terakhir, kita menggabungkan " Jeff " dengan literal string yang sama yang ditentukan di baris pertama. Jika, beberapa bulan kemudian, seseorang ingin mengubah nilai pada baris ketiga, dia harus menghabiskan waktu ekstra untuk mencari di mana lagi " Jeff " digunakan dalam metode ini. Untuk menghindari tersangkutnya data ini, Anda harus memasukkan variabel.