Adlandırma kuralı: Son alanlar (statik değil)

Bugün bir meslektaşımla finalJava sınıflarındaki alanların isimlendirilmesi hakkında bir tartışma yaptım .

İfadesinde final, örneklerin oluşumundan sonra değerleri değişmeyeceğinden, sabit alanları da dikkate alınmalıdır.

Bu, finalalanlar için aşağıdaki adlandırma kurallarına yol açacaktır :

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

    private final String BAR_BATZ;

    ...
}

Bence sadece static finalalanlar sabit kabul edilirken, sadece finalnormal alanlar CamelCase adlandırma kurallarına uymalıdır.

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

    private final String barBatz;

    ...
}

Şimdi benden çok daha deneyimli bir programcı olduğundan biraz kararsızım ve genellikle onun fikirlerine katılıyorum ve onu çok iyi bir geliştirici olarak görüyorum.

Bu konuda herhangi bir giriş var mı?

Sun (ve şimdi Oracle) , Java Programlama Dili için Kod Kuralları adlı bir belge tuttu . Bu konuda yapılan en son güncelleme '99 yıllarındaydı, ancak stil kılavuz çizgisinin özü devam ediyor.

Bölüm 9 , adlandırma kurallarını kapsar.

'Sabit' tanımlayıcı türü için:

Sınıf sabitleri ve ANSI sabitlerinin bildirilen değişkenlerinin adları, alt çizgi ("_") ile ayrılmış sözcüklerle büyük harf olmalıdır. (Hata ayıklama kolaylığı için ANSI sabitlerinden kaçınılmalıdır.)

Verilen örnekler:

static final int MIN_WIDTH = 4;

static final int MAX_WIDTH = 999;

static final int GET_THE_CPU = 1;

Daha yeni bir belgede - orada kaymış. Gönderen Java Dil> Dil Öğrenme Temelleri Değişkenler (Java Tutorials> :

Seçtiğiniz ad yalnızca bir kelimeden oluşuyorsa, o kelimeyi tüm küçük harflerle heceleyin. Birden fazla kelimeden oluşuyorsa, takip eden her kelimenin ilk harfini büyük harf kullanın. İsimler gearRatiove currentGearbu sözleşmenin başlıca örnekleridir. Değişkeniniz gibi sabit bir değer static final int NUM_GEARS = 6depolarsa, sözleşme biraz değişir, her harfi büyük harf yapar ve sonraki sözcükleri alt çizgi karakteriyle ayırır. Geleneksel olarak, alt çizgi karakteri hiçbir zaman başka bir yerde kullanılmaz.

Java için birçok statik analizör bunu zorlamak istiyor. Örneğin checkstyle uygular:

Sabit adların format özelliği tarafından belirtilen formata uygun olduğunu kontrol eder. Sabit, statik ve son bir alandır veya serialVersionUIDve dışındaki bir arayüz / açıklama alanıdır serialPersistentFields. Biçim normal bir ifadedir ve varsayılan olarak ^[A-Z][A-Z0-9]*(_[A-Z0-9]+)*$.

Bu gerçekten , kodun yazıldığı ve ideal olarak aynı kalması gereken topluluğun sözleşmelerine bağlanır .

Yukarıdaki örnekler static final, muhtemelen C sözleşmelerinden türetilmiş olanlar olarak verilmiştir #define- ki bu, C gibi, çalışma zamanında değil derleme sırasında kodda değiştirilmiştir.

O zaman sorulması gereken soru, "bu bir sabit gibi mi davranıyor? Yoksa bir kez yazılan alan gibi mi davranıyor?" - ve buna göre sözleşmeleri takip etmek. Böyle bir soru için turnuva testi "Nesneyi serileştirecekseniz, son alanı dahil eder misiniz?" Cevap sabitse, o zaman ona böyle davran (ve seri hale getirme). Öte yandan, seri hale getirilmesi gereken nesnenin durumunun bir parçası ise, o zaman bir sabit değildir.

Durum ne olursa olsun, doğru veya yanlış olmasına rağmen kod stiline bağlı kalmak önemlidir. Daha kötüsü, bir projedeki tutarsız sözleşmelerden, yalnızca göze zarar veren bir şeyden doğar. Bazı statik analiz araçları almayı düşünün ve tutarlılığı sağlamak için bunları yapılandırın.

BAR_BATZBu örnekte bir sabit değildir. Kurucuları Foo, nesne düzeyinde farklı değerlere ayarlayabilir. Örneğin

public class Foo {
    private final String BAR_BATZ;

    Foo() {
       BAR_BATZ = "ascending";
    } 

    Foo(String barBatz) {
       BAR_BATZ = barBatz;
    }
}