Konvensi penamaan: Bidang terakhir (bukan statis)


23

Hari ini saya berdiskusi dengan rekan kerja tentang penamaan finalbidang di kelas Java.

Dalam finalbidang opionionnya juga harus dianggap konstanta karena nilainya tidak akan berubah setelah pembuatan instance.

Ini akan mengarah pada konvensi penamaan untuk finalbidang berikut:

public class Foo {
    private static final String BLA_BLA = "bla";

    private final String BAR_BATZ;

    ...
}

Menurut pendapat saya hanya static finalbidang yang harus dianggap konstanta sementara bidang yang hanya finalharus mengikuti konvensi penamaan camelCase biasa.

public class Foo {
    private static final String BLA = "bla";

    private final String barBatz;

    ...
}

Sekarang saya agak tidak pasti karena dia adalah programmer yang jauh lebih berpengalaman daripada saya dan saya biasanya setuju dengan pendapatnya dan menganggapnya sebagai pengembang yang sangat baik.

Ada masukan tentang ini?


Contoh Anda bukan konstanta; Anda belum memberikan nilai apa pun kepada mereka pada waktu kompilasi. Ergo, mereka tidak mengikuti konvensi penamaan untuk konstanta.
Robert Harvey

@RobertHarvey Terima kasih, Anda benar. Itu ...dimaksudkan untuk melambangkan konstruktor yang mungkin yang menetapkan finalbidang, tapi itu jelas tidak mungkin untuk static finalbidang.
Sascha Wolf

1
@Zeeker Anda mungkin tertarik pada static { }blok yang dapat digunakan untuk mengatur bidang statis di dalam kelas satu kali ketika kelas dimuat. Terkait Bekerja dengan konstruktor statis di Jawa .

@RobertHarvey Saya kenal dengan itu. Tapi terima kasih.
Sascha Wolf

1
Saya akan mengatakan bahwa karena variabel milik instance, itu akan berbeda dari instance ke instance, jadi itu tidak berlaku sebagai konstanta. Saya akan menggunakan kasing unta.
Florian F

Jawaban:


20

Sun (dan sekarang Oracle) memelihara sebuah dokumen berjudul Konvensi Kode untuk Bahasa Pemrograman Java . Pembaruan terakhir untuk ini adalah di '99, tetapi esensi dari garis panduan gaya hidup.

Bab 9 membahas konvensi penamaan.

Untuk jenis pengidentifikasi 'konstanta':

Nama-nama variabel yang dideklarasikan sebagai konstanta kelas dan konstanta ANSI harus semuanya huruf besar dengan kata-kata yang dipisahkan oleh garis bawah ("_"). (Konstanta ANSI harus dihindari, untuk memudahkan debugging.)

Contoh-contoh yang diberikan:

static final int MIN_WIDTH = 4;

static final int MAX_WIDTH = 999;

static final int GET_THE_CPU = 1;

Dalam dokumen yang lebih baru - itu tergelincir di sana. Dari Variabel (Tutorial Java> Mempelajari Bahasa Jawa> Dasar-Dasar Bahasa :

Jika nama yang Anda pilih hanya terdiri dari satu kata, eja kata itu dalam semua huruf kecil. Jika terdiri dari lebih dari satu kata, kapitalkan huruf pertama dari setiap kata berikutnya. Nama-nama gearRatiodan currentGearmerupakan contoh utama dari konvensi ini. Jika variabel Anda menyimpan nilai konstan, seperti static final int NUM_GEARS = 6, konvensi berubah sedikit, huruf besar setiap huruf dan pisahkan kata-kata berikutnya dengan karakter garis bawah. Dengan konvensi, karakter garis bawah tidak pernah digunakan di tempat lain.

Banyak analisa statis untuk Java berusaha untuk menegakkan ini. Misalnya checkstyle memberlakukan:

Pastikan nama konstan sesuai dengan format yang ditentukan oleh properti format. Konstanta adalah bidang statis dan final atau bidang antarmuka / anotasi, kecuali serialVersionUIDdan serialPersistentFields. Formatnya adalah ekspresi reguler dan default untuk ^[A-Z][A-Z0-9]*(_[A-Z0-9]+)*$.


Ini benar-benar bermuara pada konvensi komunitas yang menulis kode ... dan idealnya menjaganya tetap sama.

Contoh di atas diberikan sebagai contoh static finalyang kemungkinan berasal dari konvensi C untuk #define- yang seperti C, diganti dalam kode selama kompilasi daripada pada saat runtime.

Pertanyaan yang kemudian harus ditanyakan adalah "apakah ini berperilaku seperti sebuah konstanta? Atau apakah itu berperilaku seperti bidang yang pernah ditulis?" - dan kemudian mengikuti konvensi yang sesuai. Tes lakmus untuk pertanyaan seperti itu adalah "Jika Anda membuat serial objek, apakah Anda akan memasukkan bidang terakhir?" Jika jawabannya adalah konstanta maka perlakukan seperti itu (dan jangan diserialisasi). Di sisi lain, jika itu adalah bagian dari keadaan objek yang perlu diserialisasi, maka itu bukan konstanta.

Apapun masalahnya, penting untuk tetap dengan gaya kode namun benar atau salah itu. Masalah yang lebih buruk muncul dari konvensi yang tidak konsisten dalam suatu proyek daripada hanya sesuatu yang menyinggung mata. Pertimbangkan untuk mendapatkan beberapa alat analisis statis dan konfigurasikan untuk mempertahankan konsistensi.



@RobertHarvey Saya bisa membayangkan beberapa situasi di mana bidang contoh berperilaku seperti konstan. Sebuah Pabrik, misalnya, mengisi sesuatu yang seharusnya menjadi konstan di objek ... meskipun ini sampai ke contoh yang agak dibuat-buat yang menyakiti kepalaku hanya berpikir tentang mengapa orang melakukannya.

Terima kasih atas jawaban terinci ini. Tes lakmus tentang serialisasi objek membuat kesepakatan untuk saya.
Sascha Wolf

Seorang kolega membuat poin yang valid baru-baru ini mengatakan bahwa, pada suatu waktu, editor tidak terlalu baik dalam menyoroti final statis / statis dll, jadi konvensi penamaan ini penting. Saat ini IDE cukup bagus, jadi kita mungkin dapat membuat nama yang tampak lebih bagus untuk mereka, misalnya: MinWidthbukannya MIN_WIDTH. Pertanyaan lain adalah: bagaimana dengan pembalakan akhir statis? Apakah Anda memanggil mereka LOG/ LOGGERatau log/ logger. Secara pribadi, logterlihat lebih baik sejalan dengan kode, tetapi kapan inkonsistensi dapat diterima, jika sama sekali?
ndtreviv

5

BAR_BATZbukan konstanta dalam contoh ini. Konstruktor dari Foodapat mengaturnya ke nilai yang berbeda di tingkat objek. Sebagai contoh

public class Foo {
    private final String BAR_BATZ;

    Foo() {
       BAR_BATZ = "ascending";
    } 

    Foo(String barBatz) {
       BAR_BATZ = barBatz;
    }
}
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.