ELSE kötü programlama kullanıyor mu? [kapalı]

Sık sık ELSEyapıyı kullanmaktan kaynaklanan hatalarla karşılaştım . Bunun en iyi örneği, aşağıdakiler doğrultusunda bir şeydir:

If (passwordCheck() == false){
    displayMessage();
}else{
    letThemIn();
}

Bana göre bu güvenlik problemi bağırıyor. PasswordCheck'in bir boolean olacağını biliyorum, ancak uygulamalarımın güvenliğini buna koymam. Bir dize, int vb ise ne olur?

Ben genellikle kullanmaktan kaçınmaya çalışıyorum ELSEve bunun yerine ne beklediğimi test etmek için iki tamamen ayrı IF deyimlerini tercih ediyorum. O zaman ya görmezden gelinir VEYA özel olarak ele alınır.

Elbette bu, uygulamanıza giren hataları / güvenlik sorunlarını önlemenin daha iyi bir yoludur.

Bunu nasıl yapıyorsunuz?

elseBlok her zaman varsayılan davranış olmasını istediklerini oluşmalıdır.

Onlardan kaçınmaya gerek yok, sadece uygun şekilde kullanmaya dikkat edin.

Örneğin, varsayılan durum erişime izin vermemelidir. Biraz yeniden düzenleme sizi şunlarla bırakır:

If (passwordCheck)
{
   letThemIn();
}
else
{
   displayMessage();
}

örn. şifre kontrolü çalışırsa, içeri girin, aksi takdirde bazı hata mesajlarını göstermek daima geçerlidir.

Elbette else iftamamen ayrı ififadeler kullanmak yerine mantığınıza ek kontroller ekleyebilirsiniz .

Hayır, yanlış bir şey yok ELSE. ELSEyeni değil GOTO. Aslında, IFyerine iki s kullanmak ELSEbirkaç soruna yol açabilir.

Birinci örnek:

if (this(is(a(very())==complex(check())))) {
   doSomething();
}

if (!this(is(a(very())==complex(check())))) {
   doTheOtherThing();
}

Kopyala-yapıştır'ı görüyor musunuz? Sadece birini değiştirip diğerini unutduğunuz günü bekler.

İkinci örnek:

foreach(x in y) {
  if (first_time) {
    first_time = false;
    doSomething();
  }

  if (!first_time) {
    doTheOtherThing();
  }
}

Gördüğünüz gibi IF, koşul zaten değiştiğinden, ikinci öğe de ilk öğe için yürütülür. Gerçek dünya programlarında, bu tür hataların fark edilmesi daha zordur.

Her zaman bir ELSE vardır. Yazarsan

if(foo)
  bar();

aslında yazıyorsun

if(foo)
{
  bar();
}
else
{
   // do nothing
}

ELSE yoluna koyduğunuz her şey sizin sorumluluğunuzdadır.

Kişisel elseolarak elimden geldiğince kaçınma eğilimindeyim , ancak bu herhangi bir güvenlik sorunu için değil .

Kodu okurken, iç içe ifadeler mantığı takip etmeyi zorlaştırır, çünkü hangi koşulların orada yol açacağını hatırlamanız gerekir. Bu nedenle, ben erken çıkış büyük bir hayranıyım:

if (checkPassword != OK) { displayMessage(); return; }

letThemIn();

Bu aynı zamanda kullanacağım forve whiledöngüler için de geçerlidir continueve breakne zaman girintiden kaçınırsa.

Chris Lattner bunu LLVM Kodlama Standartlarında benden daha iyi söylüyor .

Sonra onları değiştirin,

If (passwordCheck == true)
{
     letThemIn();
}
else
{
     displayMessage();
}

Matthieu M. gibi ben de derinden iç içe geçmiş başka bloklara erken çıkmayı tercih ederim ... İyi savunma programlamasını gösterir (kötü koşullar varsa, devam etmenin anlamı yok). Birçok insan bizimle aynı fikirde değil, çıkış noktasını tercih ediyor; tartışmanın konusu değil (sanırım).

Şimdi, elseözellikle basit, kısa alternatifler için mantıklı olduğunda kesinlikle kullanıyorum . Söylendiği gibi, testi çoğaltmak zaman kaybıdır (programcı ve CPU'lar), karışıklık kaynağı ve daha sonra hatalar (biri değiştiğinde diğeri değil).
Bazen, elsedurumun ne olduğunu (özellikle ifparça uzunsa, örneğin eski kodda) veya alternatifin ne olduğunu hatırlatarak parçaya bir yorum ekliyorum .

İşlevsel programlamanın bazı aşırı taraftarlarının, ifdesen eşleştirme lehine tamamen kurtulmayı önerdiğini unutmayın ... Benim zevkime göre biraz fazla. :-)

ELSE kullanımında yanlış bir şey yok. Ancak, okunması ve anlaşılması zor olan aşırı karmaşık koda yol açabilir. Kötü bir tasarımı gösterebilir. Test edilmesi gereken ek kullanım durumlarını kesinlikle gösterir.

Mümkünse ELSE'leri çıkarmaya çalışın - ancak paranoyak olma. Steve McConnell Code Complete'de bu düz çizgi kodunu çağırır. Yani kodunuzda basit ve net bir yol var.

Sorununuz için denemek için yaklaşımlar:

• polimorfizm kullanın. Sisteminizin sınırında kullanıcının güvenlik kimlik bilgilerini doğrulayın. Meşru ise, sistemin ilgili bölümlerine erişerek veya bir istisna atarak bir oturum nesnesi döndürün. Ancak bu, sistemi daha karmaşık hale getirebilir. Böylece, neyin daha kolay anlaşılıp sürdürüleceğine siz karar verirsiniz.

Genel olarak - aşağıdakiler kodunuzdaki ELSE'leri azaltmaya yardımcı olabilir:

• iyi gereksinimler kodda bu tür kararlara duyulan ihtiyacı azaltabilir. Kullanım senaryosunu (başka) hiç uygulamanız gerekmeyebilir.
• daha net tasarım. Maksimum kohezyon ve kuplajı en aza indirin. Bu, bileşenlerin diğer bileşenlerde alınan kararları kopyalamamasını sağlar.
• hata durumlarını yönetmek için kural dışı durum işleme.
• polimorfizm (yukarıdaki örneğe bakınız).
• anahtar ifadeleri - bunlar yüceltilen ELSE'lerdir, ancak bazı durumlarda daha iyidir.

Kodun güvenlik sızıntısı olduğu hakkındaki varsayımınız , kullandığınız dile bağlı olarak doğru olabilir veya olmayabilir . C kodunda bir sorun olabilir (özellikle C'de bir boole yalnızca sıfır veya sıfır olmayan bir int olduğundan) - ancak passwordCheckdeğişken bir boolean olarak bildirilmişse en güçlü yazılan dillerde (yani çalışma zamanı türü denetimi) , ona başka bir şey atamanın bir yolu yok. Aslında, ifmantıksal işleçleri kullanın ya da sadece değeri kullanın, bir yüklemdeki her şey bir boole'ye çözümlenmelidir. Çalışma zamanına bağlı başka bir nesne türünü yönetmeyi başardıysanız, bir tür passwordCheckyasadışı döküm istisnası atar.

Basit if / else yapılarının okunması if / if yapılarından çok daha kolaydır - ve birisi yapıyı çevirmeye çalıştığında yanlışlıkla sorunlara daha az eğilimlidir. Aynı örneği bir saniyeliğine ele alalım:

if(passwordCheck == false) {
    denyAccess();
}

if(passwordCheck) {
    letThemIn();
}

Yukarıda yürütmek istediğiniz birbirini dışlayan tümceciklerin anlamı kaybolur. İf / else yapısının anlattığı budur. Birinin her zaman çalışacağı, birbirini dışlayan iki yürütme dalı. Bu, güvenliğin önemli bir parçasıdır - aradıktan letThemInsonra bunu yapmanın yolu yoktur denyAccess.

Kodun anlaşılır olması ve kritik bölümlerin en iyi şekilde korunmasını sağlamak amacıyla, bunlar birincil fıkra ( ifbölüm) içinde olmalıdır . Varsayılan uyumlu olmayan davranış, alternatif cümlede ( elseparça) olmalıdır. Örneğin:

if(passwordCheck) {
    letThemIn();
} else {
    denyAccess();
}

NOT: Farklı dillerle çalışırken, "ya bir dize olursa?" Sorusunu önlemeye yardımcı olan bir kodlama alışkanlığı geliştirdim. Esasen, sabiti ilk olarak boole ifadesinde koymaktır. Örneğin, kontrol etmek yerine kontrol passwordCheck == falseediyorum false == passwordCheck. Bu ayrıca C ++ 'da yanlışlıkla atama sorununu önler. Bu yaklaşımı kullanarak, derleyici yazmam =yerine şikayet edecek ==. Java ve C # gibi dillerde derleyici, if yan tümcesindeki atamayı hata olarak ele alır, ancak C ++ bunu memnuniyetle kabul eder. Bu yüzden birinciyle null kontrol yapma eğilimindeyim null.

Dilleri düzenli olarak değiştirirseniz, sabiti önce yerleştirmek çok yardımcı olur. Ancak, ekibimde kodlama standardının tersidir ve derleyici bu sorunları yine de yakalar. Kırılması zor bir alışkanlık olabilir.

elseProgramlama yaparken kullanmanın kötü olduğunu söylemek, otherwisekonuşma yaparken kullanmanın kötü olduğunu söylemek gibidir .

Elbette, ikisi de kötü şekillerde kullanılabilir, ancak bu, onları dahil eden bir hata yaptığınız için kaçınılması gerektiği anlamına gelmez. Birçok hata default, bir switchifadede eksik bir duruma bağlıysa şaşırmazdım .

ElseUygulama akışınızı beyaz listeleyen olarak düşünün . Uygulama akışının devam etmesine izin vermesi gereken koşulları kontrol edersiniz ve bunlar karşılanmazsa, Elsesorunu çözmek, uygulama yürütmeyi durdurmak veya benzer bir şey yapmak için yürütülürsünüz.

Else kendi başına kötü değildir, ancak kötü kullanırsanız, istenmeyen etkiler görebilirsiniz.

Ayrıca,

"PasswordCheck'in büyük olasılıkla bir boole olacağını biliyorum, ancak uygulama güvenliğimi buna koymam."

Geliştirdiğiniz yöntemler için DAİMA bir veri türü döndürür. Her ne kadar PHP Core iki veya daha fazla veri tipi döndüren kodlarla doluysa da, işlev çağrılarını tahmin ettiği için bu kötü bir uygulamadır. Birden fazla veri türü döndürmeniz gerekiyorsa, bir istisna atmayı düşünün (bunun genellikle başka bir veri türünü döndürmek istememin nedeni olduğunu düşünüyorum - bir şey korkunç, korkunç bir şekilde yanlış gitti) veya kodunuzu yeniden yapılandırmayı düşünebilirsiniz. yalnızca bir veri türü döndürür.

Her şeyden önce. LOL! Başka hiçbir şeyden kaçınmak için NEDEN YOKTUR. Herhangi bir şekilde, şekilde veya biçimde kötü uygulama DEĞİLDİR.

Bir şey varsa kod

if(!IsLoggedIn) { ShowBadLoginOrNoAccessPage(); return }

Orada iki ifs yok ve başka yok. Bu benim bir istisna atmak dışında biri benim tüm uygulamaları yapmak. İstisna, uygun sayfanın gösterilmesi için URL'yi kontrol eden işlevimde yakalanır (veya alternatif olarak catch / check'yi asp.net hata işlevine koyabilirim). Yetkilendirmeyen genel bir sayfa yazdırır veya istisnada kullandığım herhangi bir iletiyi yazdırır (her zaman istisna türünü kontrol eder ve http durum kodunu ayarlarım).

-Edit- ammoQ örnek 2'de gösterildiği gibi eğer gülünçse. Gerçekten başka bir if kadar iyi veya daha iyi. Eğer bir şey ifs kaçınılması gereken (ben şahsen dont rağmen. Ama i dönüş ve çok kırmak kullanın) onun söylendiği gibi daha fazla kod yolları hata olasılığını artırmak. Bakınız Siklomatik Karmaşıklık

-Düzenle 2- if / else kullanımı konusunda endişeleriniz varsa. Ayrıca tercihimin en kısa kod bloğunu en üste koymak olduğunu da belirteceğim.

if(cond == false) {
    a()
    b()
    c()
    onetwothree()
}
else
{
    a()
    b()
    c()
    more()
    onetwothree()
    code()
    longer()
}

Aksine o zaman

if(cond) 
{
    a()
    b()
    c()
    more()
    onetwothree()
    code()
    longer()
}
else
{
    a()
    b()
    c()
    onetwothree()
}

Yapabildiğim zaman koşullardan önce bir varsayılan ayarlamayı seviyorum. Okumak biraz daha kolay ve biraz daha açık gibi hissediyorum, ama bu sadece bir tercih. Ben denemek ve benim kod negatif koşulları önlemek için bir eğilim var. Ben! Foo veya false == foo için büyük bir hayran değilim ve başka tür bir negatif koşullu eşdeğer olduğunu hissediyorum.

foo = bar;

if ('fubar' == baz) {
    foo = baz;
}

onun yerine ...

if ('fubar' == baz) {
    foo = baz;
} else {
    foo = bar;
}

Önceki kod bloğunu okumak benim için biraz daha kolay görünüyor. Kodum hakkında bir tür şüpheci paranoya sahip olmak benim için daha doğal görünüyor. Herhangi bir koşuldan bağımsız olarak varsayılan bir ayar yapmak beni rahat hissettiriyor: P

Her türlü dallanma mantığından mümkün olduğunca kaçınılması gerektiğini savunuyorum. ELSE veya IF ile ilgili hiçbir şey yanlış olmasa da, herhangi bir dallanma mantığı kullanma ihtiyacını en aza indirmek için kod yazmanın birçok yolu vardır. Dallanma mantığının tamamen ortadan kaldırılabileceğini söylemiyorum - bazı yerlerde gerekli olacak - ama iyi bir yığınını ortadan kaldırmak için kodu yeniden düzenlemek mümkün. Çoğu durumda bu, kodunuzun anlaşılırlığını ve doğruluğunu artıracaktır.

Örnek olarak, üçlü operatörler de genellikle iyi adaylardır:

If VIP Then 
  Discount = .25
Else
  Discount = 0
End If
Total = (1 - Discount) * Total

Üçlü bir yaklaşım kullanarak:

Discount = VIP ? .25 : 0
Total = (1 - Discount) * Total

Üçlü operatörler dallanmayı sağa doğru iyi bir şekilde kaydırır.