Varsayılan alan başlatmaya güvenmek - kötü programlama tarzı mı? [kapalı]


20

Resmi oracle belgelerine bir bağlantı verildi: https://docs.oracle.com/javase/tutorial/java/nutsandbolts/datatypes.html

nerede söylendi:

Varsayılan değerler

Bir alan bildirildiğinde bir değer atamak her zaman gerekli değildir. Bildirilen ancak başlatılmayan alanlar derleyici tarafından makul bir varsayılan değere ayarlanır. Genel olarak, veri türüne bağlı olarak bu varsayılan sıfır veya boş olacaktır. Bununla birlikte, bu varsayılan değerlere güvenmek genellikle kötü programlama tarzı olarak kabul edilir.

Bu kısmı vurgulamak istiyorum:

Bununla birlikte, bu varsayılan değerlere güvenmek genellikle kötü programlama tarzı olarak kabul edilir.

Ama, oh boy, bu, örnek değişkenlerinin varsayılan değerlere sahip olduğunu bilen dil belirtiminin temel bir parçasıdır. Neden Java SE kütüphaneleri kaynak kodunda bile yaygın olarak kullanılıyorsa , neden bu kötü bir programlama uygulamasıdır ?


5
Huh. Bu ifadenin orada olduğunu asla bilmiyordum. Aslında onlara güvenmenin iyi bir uygulama olduğunu düşünüyorum. private int count = 0;hiçbir şey yapmayan koddur ve hiçbir şey yapmayan kod dağınıktır. Bu, java.lang'dan sınıfları içe aktarmak veya ile bir sınıf bildirmek gibidir extends Object.
VGR

2
... veya public abstractbir arayüzde bir metoda sahip olmak .
mumpitz

1
kamuoyu özeti ile ilgili sorun nedir?
John Keates

1
Bulmacanın bir parçası C ++ 'dan gelebilir. Bu popüler bir dildir ve varsayılan başlatmayı sıfır başlatmaya karşı işleme sürekli bir hata kaynağıdır. C ++ 'da, en istisnai durumlar dışındaki tüm varsayılanlara güvenmek doğrudan kötü bir fikirdir. Bu kültürel olarak Java'ya sızmış olabilir.
Cort Ammon

@JohnKeates - Java'm biraz paslanmış, ancak privatebir arabirimdeki yöntemler hiçbir anlam ifade etmiyor ve abstractima ediliyor .
Scott Smith

Yanıtlar:


6

Alıntılanan metin:

"Ancak, bu gibi varsayılan değerlere güvenmek genellikle kötü programlama tarzı olarak kabul edilir."

Alaycı bir şekilde: "genellikle kabul edilir" çoğu zaman yazarın sunulan ifade için yetkili bir kaynak bulmaya çalışmadığını söylemenin bir yoludur.

Bu durumda iddia açıkça sorgulanabilir. Kanıt: Örneklenen 5 Java Stil Kılavuzundan 5'i varsayılan değerlere güvenmeniz gerekip gerekmediği hakkında bir şey söylemez:

(Not, örnekleme için benim yöntembilim "java tarzı kılavuzu" için ilk 5 farklı Google arama isabet bakmak oldu. Sonra her belgede "varsayılan" aradım. Bu kapsamlı bir analiz değil, ama benim açımdan göstermek için hizmet vermektedir. )


TAMAM. Peki, Java kodunun okunabilirliğine gerçekten yardımcı oluyor mu?

Bu tartışmalıdır.

Bir yandan, varsayılan başlatma hakkında bilgi sahibi olmayan acemi bir Java programcısı sıfırların veya sıfırların nereden geldiği konusunda şaşkına dönebilir. Ancak, açık bir başlatma aramaya uğraşırlar ve bir tane bulmazlarsa, varsayılan başlatma hakkında bilgi edinmek için bir öğretici veya kitap okumalarına neden olmak için yeterli olmalıdır. (Umarım!)

Öte yandan, normalde acemi Java programcılarının üretim kod tabanlarını sürdürmelerini beklemiyoruz. Deneyimli bir Java programcısı için fazladan başlatma, okunabilirliği artırmaz. (En iyi) gürültü.

Bana göre, bir alanın gereksiz başlatılmasıyla elde edilen tek şey, kodun gelecekteki bir okuyucusuna başlangıç ​​değeri hakkında düşündüğünüzü bildirmektir . (@GhostCat'in ifade ettiği gibi, varsayılan başlatma, amacı bildirmez.)

Ama tam tersine o okuyucu olsaydım, kod yazarının düşüncesine kesinlikle güvenmezdim. Dolayısıyla bu "sinyalin" değeri de sorgulanabilir.


Peki ya güvenilirlik?

Java'da fark etmez. JLS belirtir varsayılan başlatma gelmez alanlar için ortaya çıkar. Tersine, yerel değişkenler için kesinlikle başlatılmamış bir değişkeni kullanmaya çalışmak bir derleme hatasıdır.

Kısacası, açıkça başlatılmayan bir değişkenin çalışma zamanı davranışı tamamen tahmin edilebilir.

Aksine, değişkenlerin başlatılamayacağı C veya C ++ gibi dillerde, davranış belirtilmez ve çökmelere ve farklı platformlarda davranış farklılıklarına neden olabilir. Değişkenleri her zaman açıkça başlatma durumu burada çok daha güçlüdür.


Performans ne olacak?

Fark etmemeli. JIT derleyicisi yedek başlatma ve varsayılan başlatma işlemlerini aynı şekilde gerçekleştirebilmelidir.


19

Basit: varsayılan değerlere güvenmek niyetini iletmez.

Bu alanın 0 ile başlamasını gerçekten mi istediniz, yoksa bir değer atamayı mı unuttunuz ?!

Ve elbette, null referans, nullpointer istisnasına girmeniz gereken iki şeyin yarısıdır.

Son olarak, varsayılanları kullanmak, nihai olmayan alanlarınız olduğunu gösterir. Hangi mümkün olduğunca kaçının.

Tek karşı argüman: neden gerekmeyen şeyleri yazmalısınız? Ancak listelenen dezavantajların trompet olduğunu düşünüyorum, bu nedenle bir alana 0 atamak onu derleyiciye bırakmaktan daha iyi.


3
yani re: iletişim kurma niyeti - Eğer "Manny bakıcı" kodunuza bakıyorsa ve belirli bir veri türü için varsayılanın ne olduğunu bilmiyorsa. Gerçekten NULL olduğunda 0 olduğunu varsayıyor ve === çekindeki tüm hata (ya da değer ve tür için eşdeğer eşitlik denetimi java'da ne olursa olsun, eşittir ()?). Çalışma saatleri (deneyimsiz bir programcı için) bu kadar basit bir şeyin sonucu olabilir. PS şeytanın avukatı oynamaya çalışıyor. Ben bütün gün varsayılanları kullanın (asla yapmama rağmen) ve kodunu korumak için daha akıllı insanlar (veya en azından detaylara daha fazla dikkat) olsun diyorum.
TCooper

@TCooper mannie bakıcı Java hakkında çok az şey biliyorsa, o zaman gerçek dünya Java koduna dokunan bir işi yoktur. Ama altta yatan düşünceyi kabul ediyorum. Yeni başlayanlar için işleri zorlaştırır.
GhostCat, Monica C.'yi selamlıyor

12

Neden bu kötü bir programlama uygulaması

Fikir, varsayılan bir değere güveniyorsanız, kasıtlı olarak varsayılan değer olarak bırakırsanız veya onu atamayı unutursanız , kodu okuyan herkes için hemen net değildir .

... Java SE kütüphanelerinde bile yaygın olarak kullanılıyorsa kaynak kodu ??

Java kaynak kodu, örnek kodlama uygulamasına örnek olarak güvenmeniz gereken bir şey değildir. Bu tür kuralların ihlal edildiği birçok durum vardır (bazen kasıtlı olarak küçük performans iyileştirmeleri için ve bazen yanlışlıkla veya kabul edilen stil yıllar içinde değiştiği için).


2
Bu muhtemelen doğru, ancak buna katılmıyorum.
VGR

3
@VGR Varsayılan değerlere güvenmenin düşük optimal olduğu iddiasıyla hemfikir olduğum kadar, bu nedenle onu tarafsız bir şekilde ifade etmeye dikkat ettim. Kod kalitesi özneldir ve bunun evrensel olarak tutulan bir görüş olmadığının farkındayım.
Michael Berry
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.