Geliştirici, ifadelerin ihmal koşullarının olmaması ve her zaman başka bir bloğa sahip olması gerektiğinde ısrar eder

Benden daha deneyimli bir geliştiricim var. Programlama uygulamaları hakkında konuşuyorduk ve 'if' ifadeleri konusundaki yaklaşımından şaşırmıştım. Oldukça garip bulduğum ifadelerle ilgili bazı uygulamalarda ısrar ediyor.

Öncelikle , eğer bir if ifadesi, içine koymak için bir şey olup olmadığına bakılmaksızın başka bir ifade tarafından takip edilmelidir. Bu gibi görünen kod yol açar:

if(condition) 
{
    doStuff();
    return whatever;
}
else
{
}

İkincisi , yanlış yerine gerçek değerleri test etmek daha iyidir. Bu, '! DoorOpened' değişkeni yerine 'doorClosed' değişkenini test etmenin daha iyi olduğu anlamına gelir

Argümanı, kodun ne yaptığını daha açık hale getirdiğidir .

Bu beni biraz şaşırtıyor, çünkü bu iki kuralın bir kombinasyonu, şartlar karşılanmadığında bir şeyler yapmak isterse bu tür bir kod yazmasına neden olabilir.

if(condition)
{
}
else
{
    doStuff();
    return whatever;
}

Bununla ilgili hislerim gerçekten çok çirkin ve / veya varsa kalite kalitesinin ihmal edilebilir olduğudur. Ama bir çocuk olarak, içgüdülerimden şüphe duymaya meyilliyim.

Öyleyse benim sorularım: Uygulama iyi mi / kötü mü / "farketmez mi"? Yaygın pratik mi?

Açık elseblok

İlk kural sadece kodu kirletir ve ne daha okunaklı, ne de daha az hataya meyilli yapar. İş arkadaşınızın amacı - herhalde - geliştiricinin koşulun değerlendirilebileceğinin tam olarak farkında olduğunu göstererek, açık olmaktır false. Açık olması iyi bir şey olsa da, bu açıklık üç ekstra kod satırı pahasına olmamalıdır .

Bir ififadenin mutlaka elseya hiç ya da hiçbiri tarafından takip edilmemesi gerçeğinden bahsetmiyorum bile : Bir ya da daha fazla elifs tarafından da takip edilebilir .

İfadenin varlığı returnişleri daha da kötüleştirir. Aslında elseblok içinde yürütmek için kodunuz olsa bile , bu şekilde yapmak daha okunaklı olacaktır:

if (something)
{
    doStuff();
    return whatever;
}

doOtherThings();
return somethingElse;

Bu, kodun iki satırı daha az almasını sağlar ve elsebloğu ayırır . Muhafız maddeleri bununla ilgili.

Bununla birlikte, meslektaşınızın tekniğinin, boşluksuz, çok kötü bir yığılmış koşullu blok kalıbını kısmen çözebileceğine dikkat edin:

if (something)
{
}
if (other)
{
}
else
{
}

Önceki kodda, ilk satırdan sonra mantıklı bir satır sonu olmaması ifkodu yanlış yorumlamayı çok kolaylaştırır. Bununla birlikte, iş arkadaşınızın kuralı kodu yanlış okumayı zorlaştırırken, daha kolay bir çözüm basitçe yeni bir satır eklemek olacaktır.

İçin test true değil,false

İkinci kural biraz mantıklı gelebilir, fakat şu anki haliyle değil.

Kapalı bir kapı için yapılan testlerin, açılmayan bir kapı için yapılan testlerden daha sezgisel olduğu yanlış değildir . Olumsuz görüşmeler ve özellikle iç içe geçmiş olumsuzlukların anlaşılması genellikle zordur:

if (!this.IsMaster || (!this.Ready && !this.CanWrite))

Bunu çözmek için, boş bloklar eklemek yerine , gerektiğinde veya yerel değişkenler ek özellikler yaratın .

Yukarıdaki durum kolayca okunabilir hale getirilebilir:

if (this.IsSlave || (this.Synchronizing && this.ReadOnly))

İlk kurala gelince, bu işe yaramaz bir yazma örneğidir. Sadece yazmak daha uzun sürmekle kalmaz, aynı zamanda kodu okuyan herkes için büyük miktarda karışıklığa neden olur. Kod gerekli değilse, yazmayın. Bu else, kod ifbloğundan döndüğünde davanızda doldurulmayacak kadar uzar:

if(condition) 
{
    doStuff();
    return whatever;
}

doSomethingElse(); // no else needed
return somethingelse;

İkinci noktaya gelince, negatif içeren boolean adlardan kaçınmak iyidir:

bool doorNotOpen = false; // a double negative is hard to reason
bool doorClosed = false; // this is much clearer

Bununla birlikte, bunu, bir negatif için tekrar test etmemeye genişletmek, belirttiğiniz gibi, daha işe yaramaz bir şekilde yazmaya yol açar. Aşağıdakiler boş bir ifbloğa sahip olmaktan çok daha net :

if(!condition)
{
    doStuff();
    return whatever;
}

1. Boş elseifadeler lehine bir tartışma .

Çoğu zaman, o ilk yapıya benzeyen bir şeyi, boş olanı kullanır (ve tartışırız). Programcının durum hakkında bazı düşünceler içerdiğini kod okuyucularına (hem insan hem de otomatik analiz araçları) bildirir. elseOlması gereken eksik ifadeler insanları öldürdü, araçları düştü ve milyonlarca dolara mal oldu. MISRA-C, örneğin, en azından eksik finalin bir sırada kasıtlı olduğunu söyleyen bir yorumu zorunlu kılar if (condition_1) {do_this;} else if (condition_2) {do_that;} ... else if (condition_n) {do_something_else;}. Diğer yüksek güvenilirlik standartları daha da ileri düzeydedir: birkaç istisna dışında, eksik beyanlar yasaktır.

Bir istisna, satırları boyunca basit bir yorumdur /* Else not required */. Bu, üç satır başka boş olduğu gibi aynı amacı işaret eder. Boş olanın gerekmediği bir başka istisna, hem kodun okuyucuları hem de gereksiz olanı boşaltan otomatik analiz araçlarının açıkça görülmesidir. Örneğin, if (condition) { do_stuff; return; }Benzer şekilde, yerine throw somethingveya goto some_label¹ yerine boş bir başkasına gerek yoktur return.

2. if (condition)üzerinden tercih için bir argüman if (!condition).

Bu bir insan faktörüdür. Karmaşık boole mantığı birçok insanı harekete geçirir. Tecrübeli bir programcının bile düşünmesi gerekecek if (!(complex || (boolean && condition))) do_that; else do_this;. En azından, bunu tekrar yaz if (complex || (boolean && condition)) do_this; else do_that;.

3. Bu, birinin boş thenifadeleri tercih etmesi gerektiği anlamına gelmez .

İkinci bölüm "sen" yerine "tercih" diyor. Bu bir kuraldan ziyade bir kılavuzdur. Bu kılavuzun olumlu ifkoşulları tercih etmesinin nedeni , kodun açık ve net olması gerektiğidir. Boş bir boş cümlesi (örneğin, if (condition) ; else do_something;) bunu ihlal ediyor. Programlanmış bir programdır ve en deneyimli programcıların bile ifdurumu olumsuzlanmış haliyle yedeklemesine ve tekrar okumasına neden olur . Öyleyse ilk etapta olumsuzlanmış biçimde yazın ve else ifadesini atlayın (ya da zorunlu kılınması durumunda bu konuda boş bir yorum veya yorum yapın).

¹ Sonra ile sona hükümler yazdı return, throwya gotobaşka boş gerektirmez. Aksi cümlenin gerekli olmadığı açıktır. Peki ya goto? Bir kenara bırakıldığında, güvenlik açısından kritik öneme sahip programlama kuralları bazen erken dönüşe izin vermez ve neredeyse her zaman atma istisnalarına izin vermez. Bununla birlikte, gotosınırlı bir biçimde izin verirler (örneğin, goto cleanup1;). Bu sınırlı kullanım, gotobazı yerlerde tercih edilen uygulamadır. Örneğin, Linux çekirdeği bu tür gotoifadelerin tam anlamıyla doludur .

Çok nadir durumlarda boş bir başka dal (ve bazen boş bir açık dal) kullanırım: Hem eğer hem de diğer kısımların bir şekilde ele alınması gerektiği açık olduğunda, ancak önemsiz olmayan bir nedenden dolayı durumun ele alınabileceği hiçbir şey yapmamak. Bu nedenle, gerekli olan başka bir eylemle kodu okuyan herkes derhal bir şeyin eksik olduğundan şüphelenir ve zamanını boşa harcar.

if (condition) {
    // No action needed because ...
} else {
    do_else_action()
}

if (condition) {
    do_if_action()
} else {
    // No action needed because ...
}

Ama değil:

if (condition) {
    do_if_action()
} else {
    // I was told that an if always should have an else ...
}

Diğer her şey eşit olduğunda, kısalık tercih eder.

Yazmadığın şeyi kimse okumalı ve anlamalı.

Açık olmak yararlı olsa da, bu, yalnızca, yazdığınızın gerçekten yazmak istediğin şeyin gereğinden fazla bir ayrıntı olmadan açıkça ortaya çıkması durumunda ortaya çıkar.

Bu nedenle, boş dallardan kaçının, sadece işe yaramazlar, aynı zamanda nadir görülürler ve bu nedenle karışıklığa yol açarlar.

Ayrıca, doğrudan if-dalından çıkarsanız başka bir dal yazmaktan kaçının.

Açıklığın kullanışlı bir uygulaması, anahtar davalardan düştüğünüzde bir yorum koymak // FALLTHRUve boş bir ifadeye ihtiyaç duyduğunuz bir yorum veya boş bir blok kullanmak olacaktır for(a;b;c) /**/;.

Bir IF beyanı için pozitif veya olumsuz koşullar hakkında benim bilgime değil, sert ve hızlı bir kural yoktur. Kişisel olarak , olumsuz durumlarda değil, olumlu durumlarda da kodlamayı tercih ederim . Bunu kesinlikle yapmayacağım, eğer boş bir IF bloğu yapmama neden oluyorsa, ardından mantık dolu bir ELSE. Eğer böyle bir durum ortaya çıkarsa, yine de olumlu bir durum için test yapmak üzere yeniden ateşlenmesi 3 saniye alacaktır.

Yine de örneklerinizden gerçekten hoşlanmadığım şey, boş ELSE'in kapladığı tamamen gereksiz dikey alan. Bunu yapmak için hiçbir sebep yok. Mantığa hiçbir şey eklemiyor, kodun ne yaptığını belgelemeye yardımcı olmuyor ve okunabilirliği hiç arttırmıyor. Aslında, eklenen dikey boşluğun okunabilirliği azaltabileceğini savunuyorum .

Açık elseblok

Tüm ifadeleri kapsayan bir battaniye ifadesi olarak buna katılmıyorum, ifancak elsealışkanlık dışı bir blok eklemek iyi bir şeydir.

ifAklıma göre bir açıklama aslında iki farklı işlevi kapsar.

Bir şey yapmamız gerekiyorsa, burada yap.

Bu gibi şeyler tabii ki yok değil bir ihtiyaç elseparçasını.

    if (customer.hasCataracts()) {
        appointmentSuggestions.add(new CataractAppointment(customer));
    }
    if (customer.isDiabetic()) {
        customer.assignNurse(DiabeticNurses.pickBestFor(customer));
    }

ve bazı durumlarda bir elseyanıltıcı madde eklemek konusunda ısrar ediyorlar.

    if (k > n) {
        return BigInteger.ZERO;
    }
    if (k <= 0 || k == n) {
        return BigInteger.ONE;
    }

olduğu değil aynı

    if (k > n) {
        return BigInteger.ZERO;
    } else {
        if (k <= 0 || k == n) {
            return BigInteger.ONE;
        }
    }

işlevsel olarak aynı olmasına rağmen. İlkini ifboş elsebırakmak, gereksiz yere çirkin olan ikinci sonuca götürebilir.

Belirli bir durumu kontrol ediyorsak, sadece bu olayı ele elsealmanızı hatırlatmak için boş eklemek iyi bir fikirdir.

        // Count wins/losses.
        if (doors[firstChoice] == Prize.Car) {
            // We would have won without switching!
            winWhenNotSwitched += 1;
        } else {
            // We win if we switched to the car!
            if (doors[secondChoice] == Prize.Car) {
                // We picked right!
                winWhenSwitched += 1;
            } else {
                // Bad choice.
                lost += 1;
            }
        }

Bu kuralların yalnızca yeni kod yazarken geçerli olduğunu unutmayın . IMHO Boş elsemaddeler, check-in işleminden önce kaldırılmalıdır.

Deney içintrue değil,false

Yine, bu genel düzeyde iyi bir tavsiyedir ancak çoğu durumda kodu gereksiz yere karmaşık hale getirir ve daha az okunabilir hale getirir.

Gibi kod gibi

    if(!customer.canBuyAlcohol()) {
        // ...
    }

okuyucuya engel oluyor

    if(customer.canBuyAlcohol()) {
        // Do nothing.
    } else {
        // ...
    }

En azından daha kötüsü yoksa kötüdür.

Ben yıllar önce BCPL içinde kodlanmış ve bu dilde bir orada IFhüküm ve bir UNLESSçok daha okunabilecek şekilde kod böylece fıkra:

    unless(customer.canBuyAlcohol()) {
        // ...
    }

Bu önemli ölçüde daha iyi, ama yine de mükemmel değil.

Benim kişisel süreç

Genel olarak, yeni bir kod yazarken, bu olayı henüz henüz kapsamadığımı hatırlatmak elseiçin sık sık boş bir blok ekleyeceğim if. Bu DFStuzaktan kaçınmama yardımcı oluyor ve kodu gözden geçirdiğimde yapacak daha çok şey olduğunun farkına varmamı sağlıyor. Ancak, genellikle TODOtakip etmek için bir yorum eklerim .

  if (returnVal == JFileChooser.APPROVE_OPTION) {
    handleFileChosen();
  } else {
    // TODO: Handle case where they pressed Cancel.
  }

Genellikle elsekodumda nadiren kullandığımı biliyorum, çünkü kod kokusunu sıklıkla gösterebilir.

İlk olarak, IF ifadelerini bu şekilde kullanılmaya zorlayan bir dil kullandım (Opal'de, bir GUI ön ucunu ana sistemlere koymak için bir ana ekran perdesi sıyırıcısının arkasındaki dil) ve IF için yalnızca bir satır kullandım ve ELSE. Hoş bir deneyim değildi!

Herhangi bir derleyicinin bu ek ELSE maddelerini optimize etmesini beklerdim. Ancak canlı kod için hiçbir şey eklemiyor (geliştirme aşamasında daha fazla kod için yararlı bir işaret olabilir).

CASE / WHEN tipi işlemede bu fazladan cümle gibi bir şey kullandığım zamandır. Boş olsa bile daima varsayılan bir fıkra ekliyorum. Bu, uzun süredir böyle bir cümle kullanılmazsa hata çıkaran dillerin alışkanlığıdır ve işlerin gerçekten yerine getirilmesi gerekip gerekmediğine dair bir düşünceyi zorlar.

Uzun zaman önce anabilgisayar (örneğin, PL / 1 ve COBOL) uygulaması, negatif kontrollerin daha az verimli olduğu kabul edildi. Bu, 2. noktayı açıklayabilir, ancak bugünlerde mikro optimizasyon olarak göz ardı edilen çok daha önemli verimlilik tasarrufları olmasına rağmen.

Negatif mantık, bu kadar basit bir IF ifadesinde çok fazla olmasa da, daha az okunabilir olma eğilimindedir.

İkinci olarak, boş elseblokların hemen hemen her zaman zararlı bir elektronik mürekkep israfı olduğuna dair cevapların çoğunu söylerdim . Bunu yapmak için çok iyi bir nedeniniz yoksa bunları eklemeyin, bu durumda boş blok hiç boş olmamalıdır, neden orada olduğunu açıklayan bir yorum içermelidir.

Olumsuzluklardan kaçınmayla ilgili sorun yine de biraz daha fazla ilgiyi hak ediyor: Genellikle, bir boole değeri kullanmanız gerektiğinde, ayarlandığında çalışmak için bazı kod bloklarına ve ayarlanmadığında çalışmak için diğer bazı bloklara ihtiyacınız vardır. Dolayısıyla, negatif olmayan bir kural uygularsanız,if() {} else {...} ifadeleri (boş bir ifblokla!) da reddedilen değerini içeren her bir boole için ikinci bir boolean yaratırsınız. Her iki seçenek de okuyucuların kafasını karıştırdığından kötü.

Yararlı bir politika şudur: Asla bir booleanın adı içinde olumsuzlanmış bir form kullanmayın ve olumsuzlamayı tek olarak ifade edin !. Gibi bir ifade if(!doorLocked)tamamen açık, if(!doorUnlocked)düğüm beyin gibi bir ifadedir . Daha sonra ifade türü, !bir if()koşulda tek bir kişinin varlığı değil, ne pahasına olursa olsun kaçınmanız gereken şeydir .

Bunun kesinlikle kötü bir uygulama olduğunu söyleyebilirim. Başka ifadeler eklemek, kodunuza hiçbir şey yapmayan ve okumayı daha da zorlaştıran çok sayıda anlamsız satır ekleyecektir.

Boş bir if-blok olan ikinci durumu ele almakla ilgili henüz bahsetmemiş başka bir kalıp var. Bununla başa çıkmanın bir yolu, if bloğuna geri dönmek olacaktır. Bunun gibi, böyle:

void foo()
{
    if (condition) return;

    doStuff();
    ...
}

Bu, hata koşullarını kontrol etmek için kullanılan yaygın bir kalıptır. Olumlu durum hala kullanılmaktadır ve bunun içi artık bir operasyonun kasıtlı olup olmadığını merak etmek için gelecekteki programcıları bırakmaktan boş değildir. Ayrıca, yeni bir işlev yapmanız gerekebileceğinden okunabilirliği artırabilir (böylece büyük işlevleri daha küçük bireysel işlevlere böler).

Başka bir cevapta görmediğim "her zaman başka bir cümleye sahip" argümanını dikkate alırken bir nokta var: işlevsel bir programlama tarzında mantıklı olabilir. Sırala.

İşlevsel bir programlama tarzında, ifadeler yerine ifadelerle ilgilenirsiniz. Dolayısıyla her kod bloğunun bir dönüş değeri vardır - bir if-then-elseifade dahil . Ancak bu, boş bir elsebloğu engeller. Bir örnek vereyim:

var even = if (n % 2 == 0) {
  return "even";
} else {
  return "odd";
}

Şimdi, C stili veya C stili esin kaynağı olan sözdiziminde (Java, C # ve JavaScript gibi, sadece birkaçını belirtmek gibi) dillerde bu garip görünüyor. Ancak böyle yazıldığında çok daha tanıdık geliyor:

var even = (n % 2 == 0) ? "even" : "odd";

elseŞubeyi burada boş bırakmak bir değerin tanımlanmamasına neden olur - çoğu durumda, işlevselliği programlamada geçerli bir durum olmak istediğimiz şey değildir. Tamamen dışarıda bırakmakla aynı şey. Ancak, yinelemeli bir şekilde programlama yaparken her zaman bir elsebloğa sahip olmak için çok az neden belirledim .

... bir if ifadesini, içine koymak için bir şey olup olmadığına bakılmaksızın başka bir ifade izlemelidir.

Katılmıyorum if (a) { } else { b(); }olarak yeniden yazılmalı if (!a) { b(); }ve if (a) { b(); } else { }yeniden yazılmalı if (a) { b(); }.

Ancak, nadiren boş bir dalım olduğuna dikkat çekiyor. Bunun nedeni normalde boş olan dallara girdiğimi kaydetmem. Bu sayede sadece log mesajlarının dışında gelişebilirim. Nadiren bir hata ayıklayıcı kullanırım. Üretim ortamlarında hata ayıklayıcı alamazsınız; geliştirmek için kullandığınız araçlarla üretim sorunlarını giderebilmek çok güzel.

İkincisi, yanlış yerine gerçek değerleri test etmek daha iyidir. Bu, '! DoorOpened' değişkeni yerine 'doorClosed' değişkenini test etmenin daha iyi olduğu anlamına gelir

Bununla ilgili karışık hislerim var. Sahip bir dezavantaj doorClosedve doorOpenedpotansiyel olduğunu bilmeniz gerekir kelimeler / terimler sayısını iki katına çıkarır. Diğer bir dezavantaj zaman içinde anlamlıdır doorClosedvedoorOpened değiştirebilir değişebilir (sizden sonra gelen diğer geliştiriciler) ve artık birbirlerinin kesin olarak olumsuzlanamayacağı iki özellikle sonuçlanabilir. Olumsuzluklardan kaçınmak yerine, kodun dilini (sınıf adları, değişken adları vb.) İşletme kullanıcılarının sözlüğüne ve verdiğim gereksinimlere uyarlamaya değer veriyorum. Önlemek için tamamen yeni bir terim yapmak istemem!Bu terimin yalnızca işletme kullanıcılarının anlayamayacağı bir geliştirici için anlamı varsa. Geliştiricilerin, kullanıcılar ve yazma gereksinimleri ile aynı dili konuşmasını istiyorum. Şimdi eğer yeni terimler modeli sadeleştirirse, o zaman bu önemlidir, ancak şartlar sonuçlanmadan önce değil sonra ele alınmalıdır. Geliştirme, kodlamaya başlamadan önce bu sorunu çözmelidir.

İçgüdülerimden şüphe duymaya meyilliyim.

Kendini sorgulamaya devam etmek iyidir.

İyi mi / kötü mü / "farketmez" alıştırması mı?

Bir dereceye kadar bunun bir önemi yok. Kodunuzu gözden geçirin ve ekibinize uyarlayın. Bu genellikle yapılacak doğru şeydir. Ekibinizdeki herkes belirli bir şekilde kodlamak isterse, bu şekilde yapmak en iyisidir (1 kişiyi değiştirmek - kendiniz - bir grup insanı değiştirmekten daha az hikaye puanı alır).

Yaygın pratik mi?

Boş bir dal gördüğünü hiç hatırlayamıyorum. Olumsuzluktan kaçınmak için insanların yeni özellikler eklediğini görüyorum.

Sorunun sadece ikinci kısmını ele alacağım ve bu, endüstriyel sistemlerde çalışma ve gerçek dünyadaki cihazları manipüle etme bakış açımdan geliyor.

Ancak bu, bir cevaptan ziyade, genişletilmiş bir yorumdur.

Belirtildiği zaman

İkincisi, yanlış yerine gerçek değerleri test etmek daha iyidir. Bu, '! DoorOpened' değişkeni yerine 'doorClosed' değişkenini test etmenin daha iyi olduğu anlamına gelir

Argümanı, kodun ne yaptığını daha açık hale getirdiğidir.

Benim görüşüme göre, burada en azından üçlü bir durum olduğunda kapı durumunun ikili bir durum olduğu varsayılmaktadır:

1. Kapı açık.
2. Kapı tamamen açık veya tamamen kapalı değil.
3. Kapı kapatıldı.

Böylece, tekli, ikili bir dijital sensörün bulunduğu yere bağlı olarak, yalnızca iki konseptten birini tahmin edebilirsiniz:

1. Sensör kapının açık tarafında ise: Kapı açık veya açık değil
2. Sensör kapının kapalı tarafında ise: Kapı kapalı veya kapalı.

Ve bu kavramları ikili bir olumsuzlama kullanarak değiştiremezsiniz. Böylece doorClosedve !doorOpenedmuhtemelen eş anlamlı değildir ve onlar eşanlamlı olduklarını iddia yönelik herhangi bir girişimin gerçekte olandan daha sistem durumunun daha büyük bir bilgi varsayar hatalı düşünmedir.

Sorunuza geri dönerken, değişkenin temsil ettiği bilgilerin kaynağına uyan sözlüğü destekleyeceğim. Bilgi daha sonra devam kapının kapalı tarafı elde edilir Bu nedenle, eğer doorClosedvb Bu kullanılarak anlamına gelebilir ya doorClosedveya !doorClosedreddi kullanımı ile bir karışıklık sonuçlanan gerektirdiği şekilde çeşitli tablolarda, gerektiği şekilde. Ancak yapmaması gereken, sistemin durumuna ilişkin varsayımları dolaylı olarak yaymaktır.

Yaptığım işin tartışma amaçları için, sistemin durumu hakkında edindiğim bilgi miktarı, genel sistemin kendisi için gerekli olan işlevselliğe bağlıdır.

Bazen sadece kapının kapalı mı yoksa kapalı mı olduğunu bilmem gerekir. Bu durumda sadece tek bir ikili sensör yeterli olacaktır. Ancak diğer zamanlarda kapının açık, kapalı ya da geçiş halinde olduğunu bilmem gerekiyor. Bu gibi durumlarda ya iki ikili sensör (her bir kapı hareketinin en uç noktasında - kapının aynı anda açık ve kapalı olmasına karşı hata kontrolü ile) ya da kapının ne kadar 'açık' olduğunu ölçen bir analog sensör olacaktır.

Birincinin bir örneği, mikrodalga fırın üzerindeki kapı olabilir. Kapının kapalı veya kapalı olmasına göre fırının çalışmasını sağlarsınız. Kapının ne kadar açık olduğu umrumda değil.

İkincisinin bir örneği, basit bir motor tahrikli aktüatör olabilir. Aktüatör tamamen dışarıdayken motoru ileri sürmeyi engellersiniz. Aktüatör tamamen içeri girdiğinde motoru geriye doğru sürmeyi engellersiniz.

Temel olarak, sensörlerin sayısı ve türü, istenen işlevselliği elde etmek için neyin ihtiyaç duyulduğuna dair ihtiyaç analizine karşı sensörlerin maliyet analizini yapmaktan ibarettir.

Somut stil kuralları her zaman kötüdür. Yönergeler iyidir, ancak sonunda, kurallara uymayan bir şeyi yaparak işleri daha net hale getirebileceğiniz durumlar vardır.

Bununla birlikte, boş olan "satırları boşa harcıyor" "ekstra yazma" için çok fazla nefret var, bu sadece kötü. Gerçekten düşey boşluğa ihtiyacınız varsa, parantezleri aynı satıra taşıma argümanını oluşturabilirsiniz, ancak bu bir sorunsa, yine de {ayrı bir satıra koymamanız gerekir.

Başka bir yerde de belirtildiği gibi, başka bir bloğa sahip olmak, açıkça diğer davada bir şey olmasını istemediğinizi göstermek için çok kullanışlıdır. Çok fazla işlevsel programlama yaptıktan sonra (başka bir yerde gerekliyse), @OldCurmudgeon'dan bahsettiğimiz gibi gerçekten iki farklı kullanım durumu olduğundan bahsederseniz, if yazarken her zaman başkalarını düşünmeniz gerektiğini öğrendim. Birinde bir başkası olmalı, bir tane olmamalı. Ne yazık ki, her zaman bir bakışta söyleyebileceğiniz bir şey değil, bir linter ile bile yalnızım, dolayısıyla dogmatik “her zaman başka bir blok koy”.

'Olumsuz' söz konusu olduğunda yine mutlak kurallar kötüdür. Boş olması, eğer başka bir şeye ihtiyaç duymuyorsa, yani hepsini yazmak yerine, tuhaf olabilirse, garip olabilir! ya da bir == yanlış yanlış. Bununla birlikte, olumsuzun mantıklı olduğu birçok durum var. Yaygın bir örnek bir değeri önbelleğe almak olacaktır:

static var cached = null

func getCached() {
    if !cached {
        cached = (some calculation, etc)
    }

    return cached
}

Eğer gerçek (zihinsel / ingilizce) mantık olumsuz içeriyorsa, if ifadesi de olmalıdır.