Blok - parantez veya yok ise tek ifade? [kapalı]

Hangisi daha iyi / daha genel olarak kabul edilir?

Bu:

if(condition)
{
  statement;
}

Veya:

if(condition)
  statement;

Birincisini tercih etme eğilimindeyim, çünkü if if bloğunda gerçekte ne olduğunu söylemeyi kolaylaştıracağını düşünüyorum, başkalarının parantezleri daha sonra eklemelerini (veya unutarak bir hata oluşturmayı) kurtardığını ve tüm if ifadelerinizi yaptığını düşünüyorum. bazıları parantezli, bazıları olmayan üniforma. İkincisi, yine de, sözdizimsel olarak doğru ve kesinlikle daha kompakt. Hangisinin başkaları tarafından daha çok tercih edildiğini görmek merak ediyorum.

Birincisi daha iyi çünkü ikincisi hataya açık. Örneğin, bir şeyi hata ayıklamak için geçici olarak kodu yorum yaptığınızı varsayalım:

if(condition) 
//      statement;
otherStatement;

Veya acele kod ekleme:

if(condition) 
    statement;
    otherStatement;

Bu tabii ki kötü. Öte yandan, birincisi zaman zaman kendimi çok ayrıntılı hissediyor. Bu nedenle, yeterince kısa ve basitse, her şeyi tek bir satıra yerleştirmeyi tercih ederim:

if(condition) statement;

Bu, yapının gerçekte yaptığı şeyi yaptığı gibi görünmesini sağlayarak sözdizimsel gürültüyü azaltıyor, daha az hataya neden oluyor. Bu sözdiziminin yalnızca çok basit, kısa koşullar ve ifadeler için kullanılması koşuluyla, bunu tamamen okunabilir buluyorum.

Her zaman sadece güvende olmak için parantez kullanırım.

Bunu yazarken sorun değil, ancak birisinin gelecekte ortaya çıkacağını ve etrafına parantez koymadan başka bir ifade ekleyeceğini biliyorsunuz.

Mümkün olduğunda diş teli kullanmadan modeli tercih ediyorum .

Aşağıdaki açıklama uzuncadır. Lütfen bana eşlik et. Bu tarzı tercih etmem için zorunlu bir sebep vereceğim. Ayrıca, her zamanki karşı tartışmanın neden geçerli olmadığını düşündüğümü açıklayacağım.

(Yakın-) boş satırlar atık

Bunun nedeni kapanış parantezinin ekstra bir kod satırı gerektirmesidir - ve açılış parantezinin de stile bağlı olarak değişmesidir. ¹

Bu büyük bir anlaşma mı? Yüzeysel olarak hayır. Sonuçta, çoğu insan aynı zamanda mantıksal olarak biraz bağımsız blokları ayırmak için kodlarına boş satırlar koyar ve bu da okunabilirliği büyük ölçüde geliştirir.

Bununla birlikte, dikey alanı boşa harcıyorum. Modern monitörler aslında geniş bir yatay alana sahiptir. Ancak dikey alan hala çok, çok sınırlıdır (dik olarak çevrilmiş bir monitör kullanmıyorsanız, ki bu nadir değildir). Bu sınırlı dikey boşluk olan bir sorun: yaygın bireysel yöntemler mümkün olduğunca kısa olmalıdır ve olmadan tüm bloğu görebilirsiniz böylece o tekabül ayraçları (veya diğer blok ayraçlar) farka bir ekran yüksekliğinin en fazla olması gerektiğini kabul ediyor kaydırma.

Bu temel bir sorundur: Ekrandaki tüm bloğu artık göremediğiniz zaman, kavraması karmaşıklaşır.

Sonuç olarak, gereksiz boş satırları görmezden geliyorum. Tek boş satırların bağımsız blokları sınırlamak için çok önemli olduğu durumlarda (sadece bu metnin görsel görünümüne bakın), ardışık boş satırlar kitabımda çok kötü bir stildir (ve benim deneyimime göre genellikle acemi programcıların bir işaretidir).

Aynı şekilde, basitçe bir destek tutan ve ekonomik hale getirilebilecek çizgiler de olmalıdır. Parantezlerle sınırlandırılmış bir tek deyim bloğu, bir ila iki çizgiyi boşa harcar. Ekran yüksekliği başına sadece 50 hat çizgisiyle, bu fark edilir.

Diş telini çıkarmak belki zarar vermez

Parantezi atlamaya karşı yalnızca bir argüman var: birisi daha sonra söz konusu bloğa başka bir ifade ekleyecek ve parantez eklemeyi unutmayacak, böylece yanlışlıkla kodun anlamını değiştirecek.

Bu gerçekten büyük bir anlaşma olurdu.

Ama benim tecrübeme göre, öyle değil. Ben özensiz bir programcıyım; ve henüz programlama deneyimi benim on yılda, ben olduğunu söyleyebiliriz kez değil bir tekil bloğa fazladan deyimi eklerken parantez eklemek için unutulmuş.

Bunun yaygın bir hata olması gerektiğini bile yanlış buluyorum: bloklar programlamanın temel bir parçası. Blok düzeyinde çözünürlük ve kapsam belirleme, programcılar için otomatik, yerleşik bir zihinsel süreçtir. Beyin sadece bunu yapar (aksi takdirde, programlama konusundaki mantık çok daha zor olurdu). Diş tellerini yerleştirmeyi hatırlamak için gereken ilave bir zihinsel çaba yoktur: programcı ayrıca , yeni eklenen ifadeyi doğru bir şekilde girmeyi hatırlatır ; bu yüzden programcı zihinsel olarak bir bloğun dahil olduğunu işlemiş durumda.

Şimdi, ben am değil parantez atlayarak hataları neden olmaz diyerek. Demek istediğim, hiçbir şekilde ya da böyle bir kanıtımız olmadığı. Sadece zarar verip vermeyeceğini bilmiyoruz .

Bu yüzden birisi bana, bilimsel deneylerden toplanan, pratikte bunun gerçekten bir sorun olduğunu gösteren, zor veriler gösterebilinceye kadar, bu teori “ tam da böyle bir hikaye ” olmaya devam ediyor : hiç test edilmeyen çok zorlayıcı bir hipotez gereken olmayan bir bağımsız değişken olarak kullanılır.

¹ Bu problem bazen her şeyi - parantez dahil - aynı satıra koyarak çözülür:

if (condition)
{ do_something(); }

Ancak, çoğu insanın bunu hor gördüğünü söylemenin güvenli olduğuna inanıyorum. Dahası, diş telsiz varyantla aynı problemlere sahip olacaktı, bu yüzden her iki dünyanın da en kötüsü.

İkinciyle giderim. Daha özlü ve daha az ayrıntılı.

En düşük ortak paydaya yazmaya çalışmıyorum, bu nedenle diğer geliştiricilerin bugün programlamada en yaygın kontrol akış yapılarından birini nasıl yazacaklarını bilmelerini bekliyorum.

Aşağıdakileri kullanırım (burada fikir birliği):

if (condition) {
    any_number_of_statements;
}

Bu da mümkün:

if(condition) single_compact_statement;

Çok iyi değil, özellikle C / C ++ dillerinde:

if(condition) 
    single_compact_statement;

(Burada Python'da seçenek yok ;-)

In Perl , kullanmak istiyorum:

$C = $A**3 if $A != $B;

veya

$C = $A**3 unless $A == $B;

(Bu sözde kod değildir ;-)

Parantez yöntemini kullanıyorum - yukarıdaki tüm nedenlerden ötürü bir artı daha.

Kod birleşiyor. Otomatik birleşmelerden dolayı kırıldıysa, bu tek ifadeyle çalıştığım projelerde gerçekleştiği biliniyor. Korkunç olan şey, kod yanlış olmasına rağmen girintinin doğru görünmesidir , bu yüzden bu tür böceklerin tespit edilmesi zordur.

Ben de diş telleriyle çıkıyorum - kendi hatlarında. Seviyeleri bu şekilde tespit etmek daha kolay. Evet, dikey perde emlak israfı yapıyor ve bu gerçek bir dezavantaj. Dengede olsa, buna değer olduğunu düşünüyorum.

Diş teli yok. Başka bir programcı koduma ikinci bir ifade eklerse, birinin arabamı kullanmasına izin vermemden ve bir uçurumdan geçmelerinden daha fazla hatam yok.

Bu argümanı burada bir kereden fazla yaptık ve genel görüş birliği her zaman parantez kullanmaktır. Ana sebepler okunabilirlik / bakım kolaylığı ile ilgilidir.

Bloğa kod eklemeniz ifgerekiyorsa, ayraçları hatırlamanız / aramanız gerekmez. Gelecekteki programcılar kodu okuduğunda, parantezler her zaman belirgindir.

Artı tarafta, ReSharper otomatik olarak Visual Studio'daki tembel programcılara parantez ekleyecek ve sanırım diğer IDE'ler için de ekler olduğunu varsayıyorum .

İlk sözdizimini neredeyse istisnasız olarak kullanıyorum. Çünkü yanlış yorumlanamaz .

"Beni düşündürme" sadece kullanıcı arayüzleri için geçerli değil, millet ;-)

Ben şahsen ikinciyi tercih ederim. İlki çirkin, garip görünüyor ve yatay alanı boşa harcıyor. İkincisi ile ilgili temel problemler makrolardır ve kodunuzu daha sonra yanlış bir şekilde değiştiren insanlar.

Bunun için "makro kullanma" diyorum. Ben de "Lanet kodunu doğru gir" derim. Programlama için kullanılan her metin editörünün / IDE'nin otomatik olarak girintiyi nasıl yaptığını göz önüne alarak, bunu yapmak o kadar zor olmamalı. Emacs'ta kod yazarken, önceki satırda yanlış bir şey yazıp yazmadığımı belirlemek için otomatik girintiyi kullanırdım. Emacs çentik batırmaya başladığında, genellikle yanlış bir şey yaptığımı biliyorum.

Uygulamada, benden önce ne şekilde kodlanmış bir kongre düzenlendiğini takip ediyorum. Fakat bunlar beni rahatsız ediyor (ve Python'u kodladığımda ve bu tüm braket felaketi gittiğinde beni çok mutlu ediyor):

if (condition) {
    statement;
} // stupid extra brace looks ugly

Sonra

if (condition) // the brackets have now just become noise
{ statement; } // also can't see the indentation, harder to read

Her ne kadar dürüst olmak gerekirse, bir if ifadesindeki iki ifade, beni tek bir ifadeden çok daha fazla rahatsız ediyor. Çoğunlukla, çünkü parantez gerekli ve if ifadesinde sadece iki ifadeyle komik görünüyor.

İki hatlı sürümü parantezsiz kullanıyorum (2. form), ancak yer kazanmak için kullanmıyorum.

Bu formu kullanıyorum çünkü onu daha okunaklı, görsel olarak çekici ve yazması daha kolay buluyorum. Bu formu yalnızca bu koşullar yerine getirildiğinde kullanırım; yani ifdurumun tek bir satıra güzel bir şekilde oturması ve karşılık gelen ifadenin aşağıdaki satıra güzel bir şekilde uyması gerekir. Aksi takdirde, okunabilirliği artırmak için kaşlı ayraç kullanacağım.

Bu formu kullanırsam, ififadeden önce ve sonra (veya varsa yorumun üstünde ) boş bir satır (veya yalnızca bir ayraç içeren bir satır) olduğundan emin olun . Bu bilinçli bir şekilde takip ettiğim bir kural olmasa da, bu soruyu okuduktan sonra şimdi anlıyorum.

Ekran alanını korumak benim için bir öncelik değil. Daha fazla alana ihtiyaç duyarsam daha büyük bir ekran kullanırdım. Ekranım zaten dikkatime odaklanmam gereken herhangi bir şeyi okuyabilecek kadar büyük. Bir kerede tüm ekranımı kapatacak kadar çok kod satırına odaklanmam gerekmiyor. Eğer bir kerede daha fazla görüntülemeden anlayamadığım bir kod parçasıyla çok fazla iç içe geçmiş bir durum varsa, mantığın yeniden yapılandırma ile daha iyi temsil edilip edilemeyeceğini düşünmem gerekir.

Aşağıda, bu ififadenin bu şeklini nasıl kullandığımı gösteren bazı örnekler verilmiştir .

    string GuardConditions(Plan planForWorldDomination)
    {
        if (planForWorldDomination == null)
            throw new ArgumentNullException("planForWorldDomination");

        if (!planForWorldDomination.IsComplete())
            return "Doh!";

        planForWorldDomination.Execute();
    }

    void ProcessingLogic()
    {
        OneBlankLineAbove();

        if (simpleCondition)
            simpleStatement();

        OneBlankLineBelow();
        OneBlankLineAbove();

        // optional comment on the line above an if statement
        if (simpleCondition)
            simpleStatement();

        OneBlankLineBelow();
    }

    void Assignment(string drive)
    {
        OneBlankLineAbove();

        string prompt;
        if (simpleCondition)
            prompt = "simple assignment";
        else
            prompt = null;

        OneBlankLineBelow();
    }

    string Return()
    {
        OneBlankLineAbove();

        if (simpleCondition)
            return "simple return";
        else
            return null;

        OneBlankLineBelow();
    }

Diş teli. Her zaman. Ben onların hayranıyım çünkü kod biraz tutarlılık veriyor. Ayrıca @ dsimcha'nın yazdığı gibi - ek kod satırları eklerken hata yapma şansınız azdır.

Tek satırlık kod etrafındaki parantezlerin "çirkinliği", hata ayıklama ve / veya kod ekleme durumlarında olası olan ek işlerden daha az zararlıdır.

Şahsen ben parantez ile giderim.

Neden?

Eğer birisi gelirse ve if ifadesine kod eklemek gerekirse, kapsamın nerede olduğu% 100 açıktır.

ifBlokta ne kadar ifade olursa olsun ifadelerin biçimini tutarlı tutar .

Bununla birlikte, proje tarzı onsuz gitmek ise, buna bağlı kalın.

Neredeyse her zaman dirsekleri sadece güvenli tarafta olmak için kullanırım. Bununla birlikte, bazen bloğun içeriği gerçekten kısa ise, onları bırakıp tek satırlık hale getireceğim:

if (x==5) Console.WriteLine("It's a five!");

Parantezleri tutarlılık için tercih ediyorum, ancak çok fazla beyaz alan boşa harcamamayı tercih ediyorum (bu yüzden daha kolay biçimlendirilmiş kodlar sınırlı görüş alanımdaydı). Bu yüzden bunu yeterince kısa satırlar için yazıyorum:

If (cond) { statement; }

Genellikle diş telleri kullanırım ama kullanmadığım bazı durumlar var.

object GetObject() {
    // calculate obj1
    if(obj1 != null)
        return obj1;

    // calculate obj2
    if(obj2 != null)
        return obj2;

    // calculate obj3
    if(obj3 != null)
        return obj3;

    return defaultObj;
}

Bana göre, onları oraya eklemek aptalca olurdu. Birisi bundan sonra bir ifade eklerse return, kapsam belirleme sorunlarından daha büyük sorunlarımız var.

IDE kod formatlaması varsa, parantez kullanmıyorum.

Öte yandan, kodun otomatik biçimlendirmeyi desteklemeyen diğer editörlerde düzenlenebildiği yerlerde, diğer yazılarda belirtildiği gibi parantez koymak tehlikelidir. Ama yine de diş teli kullanmamayı tercih ediyorum ve bu benim için sorun olmadı.