Anahtar kutularını kullanırken varsayılan durum eklemek gerekli midir?

Son bir kod incelemesi sırasında , yapılacak herhangi bir şey olmasa bile, bloğun kullanıldığı defaulttüm dosyalara dava açmam istendi . Bu, davayı koymam ve içine hiçbir şey yazmam gerektiği anlamına geliyor .switchdefaultdefault

Bu yapılacak doğru şey mi? Hangi amaca hizmet eder?

Bir defaultifadenin gerekli olmadığı üç vaka olduğu görülüyor :

1. başka hiçbir durum kalmaz, çünkü içine giren sınırlı bir değer kümesi vardır switch case. Ancak bu zamanla (kasıtlı olarak veya kazayla) değişebilir default caseve kullanıcıyı yanlış bir değere göre kaydedebileceğiniz ya da uyaracağınız bir şeyde değişiklik olması durumunda, sizin için iyi olur .

2. nasıl ve nerede switch casekullanılacağını ve hangi değerlerin girileceğini biliyorsunuz. Yine, bu değişebilir ve ekstra bir işleme gerekebilir.

3. diğer durumlarda herhangi bir özel işleme gerek yoktur. Bu durumda, benden bir eklenmesi istenir default case, çünkü kabul edilen bir kodlama stilidir ve kodunuzu daha okunaklı kılar.

İlk iki dava varsayımlara dayanıyor. Dolayısıyla (düzenli kod incelemeleriniz olduğundan beri küçük olmayan bir takımda çalıştığınızı varsayarsak), bu varsayımları yapmayı göze alamazsınız. Kodunuzla kimin çalışacağını veya kodunuzdaki işlevlere / çağrı yöntemlerine çağrı yapacaklarını bilmiyorsunuz. Benzer şekilde, başkasının kodu ile çalışmanız gerekebilir. Aynı kodlama stiline sahip olmak, birinin kodunuzla başa çıkmayı kolaylaştıracaktır.

Bu yapılacak doğru şey mi? Hangi amaca hizmet eder?

Tüm kodlamalar için şirket kodlama standartlarının varsayılan bir durum gerektirmesi nadir değildir switch. Bunun bir nedeni okuyucuların sonunu bulmasını kolaylaştırmasıdır switch. Bir başka, muhtemelen daha iyi neden, durumun beklentilerinize uymadığında kodunuzun ne yapması gerektiği hakkında bir saniye düşünmenizi sağlamasıdır. İhtiyaç sebebi ne olursa olsun, eğer bir şirket standardıysa, hava sızdırmaz bir neden olmadıkça bunu takip etmelisiniz.

switchMümkün olan her koşul için durumları içerdiğini düşünüyorsanız, yapılacak en iyi şey assertvarsayılan duruma bir ifade koymaktır . Bu şekilde, biri kodu değiştirdiğinde ve istemeden switchkapsamadığınız bir koşul eklediğinde , isabet alır assertve kodun bu bölümünü ele almaları gerektiğini anlar .

Eğer senin switchtek olası durumların birkaç kapsar, ancak özel bir şey diğerleri için yapılmalıdır, varsayılan durumda boş bırakabilirsiniz. Varsayılan durumda kasıtlı olarak boş olduğunu belirtmek için bu durumda bir yorum eklemek iyi bir fikirdir, çünkü onu vuran şartlar için herhangi bir çalışma yapılması gerekmez.

Saf numaralandırma tipine "geçerseniz" varsayılan geri dönüşün olması tehlikelidir. Daha sonra numaralandırma türüne değer eklediğinizde, derleyici, kapsanmayan yeni değerlerle anahtarları vurgulayacaktır. Eğer orada varsayılan fıkra varsa, derleyici sessiz kalacak ve onu kaçırabilirsin.

Birçok bakımdan, bu soru sıkça sorulanlarla aynıdır Her seçeneği kapsayan / merdivenin sonunda bir elsemaddeye ihtiyacım var mıifelse if ?

Cevap, sözdizimsel olarak konuşursak, hayır demezsiniz. Ama bir tane var ...

Bir defaultmadde (en azından) iki nedenden ötürü olabilir:

1. Bir hata işleyicisi olarak - kesinlikle, buraya asla gelmemelisin! iddia edilebilecek bir iddia, fakat eğer öyleyse? Veri bozulması veya daha da kötüsü, doğrulanmadıkça veri doğrulaması yapılmaz, program başarısızlığına yol olmaz. Bu durumda, boş bir madde olmamalıdır!
2. Tasarım / Kod Kapsamı - akış şemasının en basit haliyle bile, bir if ifadesinden iki yol ve her zaman otherwisebir durumdan. Bunları kaynak koduna dahil etmemenin bir nedeni yoktur.

Felsefem her zaman oldukça basittir - iki seçeneğin en kötü senaryosunu değerlendirin ve en güvenli olanı seçin. Boş elseya da defaultyan tümce durumunda, en kötü durum seçenekleri şunlardır:

• Onları ekleyin: Fazladan üç veya dört satır "gereksiz" kod.
• Bunları Dahil Etmeyin: Hileli veriler veya beklenmeyen bir koşul yakalanmadı, bu da potansiyel olarak programın başarısız olmasına neden oluyor.

Overdramatic? Belki ... ama o zaman benim yazılım yanlış giderse insanları öldürme potansiyeline sahiptir. Bu riski almamayı tercih ederim.

Bir kenara, MISRA-C kurallar {eğilimleri için bilgilerini görmek} bir tavsiye defaulther boyunca maddesiniswitch

Java, 'varsayılan' bir ifadeye sahip olmanız için zorlamaz, ancak koda hiç ulaşılmasa bile (şu anda) her zaman birinin olması iyi bir uygulamadır . İşte birkaç neden:

Ulaşılamaz bir varsayılan maddeye sahip olarak, kodunuzun okuyucusuna değerleri düşündüğünüzü ve ne yaptığınızı bildiğinizi gösterirsiniz. Ayrıca gelecekteki değişikliklere izin verirsiniz, örneğin: yeni bir enum değeri eklenir, anahtar yeni değeri sessizce göz ardı etmemelidir; Bunun yerine bir İstisna atabilir veya başka bir şey yapabilirsiniz.

Girilen beklenmedik bir değeri yakalamak için (bir enum açmamış olmanız durumunda) - örneğin beklediğinizden daha büyük veya daha az olabilir.

'Varsayılan' eylemleri işlemek için - anahtarların özel davranış için olduğu yerler. Örneğin, anahtarın dışında bir değişken ilan edilebilir, ancak başlatılamaz ve her durum farklı bir şeye başlatılır. Bu durumda varsayılan değer, varsayılan değere sıfırlanabilir, böylece anahtarın hemen ardından gelen hata bir istisna alamaz.

Varsayılan değere hiçbir şey koymamaya karar verseniz bile (istisnalar, günlüğe kaydetme vb.) O zaman varsayılanın asla gerçekleşmeyeceğini düşündüğünüz bir yorum bile, kodunuzun okunabilirliğine yardımcı olabilir; ama bu kişisel tercihlere bağlı.

Ayrıca, kullandığınız dilin felsefesine bağlı olduğunu da eklerdim. Örneğin, Erlang’da, “çökmesine izin vermenin” yaygın bir yaklaşımı olduğu durumlarda, varsayılan bir durum tanımlamazsınız, ancak bunun için hazırlanmayan casebir durum ortaya çıkarsa, ifadenizin hata yapmasına izin verirsiniz .

Tüm davaları kesin ve kalıcı olarak ele almadığınız sürece, her zaman bir varsayılanınız olmalıdır. Hiçbir maliyeti yoktur ve değişen bir programda anahtar ifadenizi sürdüremememe sigortasıdır.

Başka hiçbir vakayı umursamadığınıza eminseniz, default: break; // umrumda değil ama default varsayılan, varsayılan gibi bir şey olmalıdır:

Aynı şekilde, bırakmayı düşündüğünüz etkiye yorum eklemeden, önemsiz olmayan bir vaka yapısını asla "bırakmamalısınız". Java bunu tasarım aşamasında yanlış anladı.

Düşünmek

enum Gender
{
       MALE ,
       FEMALE ;
}

ve

void run ( Gender g )
{
      switch ( g )
      {
           case MALE :
                 // code related to males
                 break ;
           default :
                 assert Gender . FEMALE . equals ( g ) ;
                 // code related to females
                 break ;
      }
}

Bunun bir MALE davası, bir FEMALE davası ve bir istisna atan varsayılan davaya göre daha üstün olduğunu iddia ediyorum.

Test aşamanız sırasında, bilgisayar g'nin FEMALE olup olmadığını kontrol edecektir. Üretim sırasında kontrol ihmal edilir. (Evet bir mikro-optimizasyon!)

Daha da önemlisi,% 100 kod kapsamı hedefinizi koruyacaksınız. İstisnalar atan varsayılan bir durum yazdıysanız, nasıl test edersiniz?