Kıvırcık parantezleri atlamak neden kötü bir uygulama olarak kabul edilir? [kapalı]

Neden herkes bana böyle bir kod yazmanın kötü bir uygulama olduğunu söylüyor?

if (foo)
    Bar();

//or

for(int i = 0 i < count; i++)
    Bar(i);

Kıvırcık parantezleri atlamakla ilgili en büyük argümanım, bazen onlarla iki kat daha fazla çizgi olabileceğidir. Örneğin, C # içindeki bir etiket için bir parlama efekti boyamak için bazı kodlar.

using (Brush br = new SolidBrush(Color.FromArgb(15, GlowColor)))
{
    for (int x = 0; x <= GlowAmount; x++)
    {
        for (int y = 0; y <= GlowAmount; y++)
        {
            g.DrawString(Text, this.Font, br, new Point(IconOffset + x, y));
        }
     }
 }
 //versus
using (Brush br = new SolidBrush(Color.FromArgb(15, GlowColor)))
    for (int x = 0; x <= GlowAmount; x++)
        for (int y = 0; y <= GlowAmount; y++)
            g.DrawString(Text, this.Font, br, new Point(IconOffset + x, y));

usingsMilyonlarca kez girintiye girmek zorunda kalmadan zincirleme yapmanın ek avantajını da elde edebilirsiniz .

using (Graphics g = Graphics.FromImage(bmp))
{
    using (Brush brush = new SolidBrush(backgroundColor))
    {
        using (Pen pen = new Pen(Color.FromArgb(penColor)))
        {
            //do lots of work
        }
    }
 }
//versus
using (Graphics g = Graphics.FromImage(bmp))
using (Brush brush = new SolidBrush(backgroundColor))
using (Pen pen = new Pen(Color.FromArgb(penColor)))
{
    //do lots of work
}

Kıvırcık parantezler için en yaygın argüman, bakım programlaması ve orijinal if ifadesi ve amaçlanan sonucu arasına kod ekleyerek ortaya çıkabilecek sorunlar etrafında döner:

if (foo)
    Bar();
    Biz();

Sorular:

1. Dilin sunduğu daha kompakt sözdizimini kullanmak yanlış mı? Bu dilleri tasarlayan insanlar akıllıdır, her zaman kullanımı kötü bir özellik koyacaklarını düşünemiyorum.
2. En düşük ortak paydayı anlamak ve onunla çalışmakta sorun yaşamamak için kod yazmalı mıyız veya yapmamalı mıyız?
3. Kaçırdığım başka bir argüman var mı?

Aslında, beni gerçekten bitiren tek zaman hata ayıklama ve bar () yorum:

if(foo)
  // bar();
doSomethingElse();

Bunun dışında, ben kullanma eğilimindedir:

if(foo) bar();

Hangi yukarıdaki dava ilgilenir.

EDIT Soruyu açıkladığınız için teşekkür ederim, katılıyorum, en düşük ortak paydaya kod yazmamalıyız.

Okuma hızı ...

Daha önce bahsedilenlerden başka. Bu noktada, eğer parantez ve beyaz boşluk içeren ifadeleri ayrıştırmak için koşullandırıldım. Bu yüzden okudum:

if (condition)
{
    DoSomething();
}

DoSomethingElse();

Okuduğumdan biraz daha hızlı:

if (condition) DoSomething();

DoSomethingElse();

Şöyle görünüyorsa biraz daha yavaş okudum:

if (condition) DoSomething();
DoSomethingElse();

Bunu bir öncekinden önemli ölçüde yavaş okudum:

if (condition) 
    DoSomething();
DoSomethingElse();

çünkü ben yardım edemem ama sadece durumda tekrar okuyun ve yazarın amaçladığını merak ediyorum:

if (condition)
{
    DoSomething();
    DoSomethingElse();
}

Zaten genel olarak ele alınmıştır, ancak aşağıdakileri okumak söz konusu olduğunda, yazarın neyi amaçladığından emin olmak için bir süre buna bakacağım. Orijinal yazarı onaylamak için bile avlayabilirim.

if (condition) 
    DoSomething();
    DoSomethingElse();

Küçük bir şeyse, şöyle yazın:

if(foo()) bar();

İki satıra bölünecek kadar uzunsa, diş telleri kullanın.

Ayrıca gerçekten gerekli olduğunda sadece parantez kullanmanın daha iyi olduğunu düşünürdüm. Ama artık değil, ana neden, çok fazla kodunuz olduğunda, daha okunabilir hale getirir ve tutarlı bir destek stiliniz olduğunda kodu daha hızlı ayrıştırabilirsiniz.

Her zaman diş telleri kullanmanın bir başka iyi nedeni, if'ye ikinci bir ifade ekleyen birinin yanı sıra, böyle bir şey olabilir:

if(a)
   if(b)
     c();
else
   d();

Diğer cümlenin aslında "if (b)" ifadesinin olduğunu fark ettiniz mi? Muhtemelen yaptınız, ama bu yakalamaya aşina olan birine güvenir misiniz?

Yani, sadece tutarlılık için ve ne zaman beklenmedik şeylerin olabileceğini asla bilmediğiniz için başka biri (her zaman aptal olan diğerleri) kodu değiştirdiğinde , her zaman parantez koyarım, çünkü kaynak kodunu daha okunabilir, ayrıştırmayı daha hızlı yapar beynin. Sadece en basit if ifadeleri için, eğer bir delegasyonun yapıldığı veya anahtar benzeri olduğu gibi, cümlenin asla uzatılmayacağını bildiğiniz gibi, parantezleri dışarıda bırakırım.

Bu her zaman kötü bir uygulama olarak kabul edilmez. Mono Projesi Kodlama Kuralları gerekli değilse küme parantezi kullanmamayı önerir. GNU Kodlama Standartları için de aynı şey geçerlidir . Bence bu her zamanki gibi kodlama standartlarında kişisel bir zevk meselesi.

Hatlar ucuz. İşlemci gücü ucuz. Geliştirici zamanı çok pahalı.

Genel bir kural olarak, kesinlikle kaynak / hız kritik bazı uygulamalar geliştirmiyorum sürece, her zaman kod yazma tarafında hata olur

(a) Başka bir geliştiricinin yaptığım şeyi takip etmesi kolay

(b) Kodun gerekebilecek belirli bölümlerini yorumlayın

(c) Bir şeyler ters giderse hata ayıklaması kolaydır

(d) İleride olması gerektiğinde kolayca değiştirilebilir (yani kod ekleme / çıkarma)

Kodun hızı veya akademik zarafeti, İş açısından bu faktörlere ikincildir. Bu, tıknaz veya çirkin kod yazmak için yola çıktığımı değil, bu benim öncelik sırasım.

Kıvırcık parantezleri çoğu durumda atlayarak, benim için (b), (c) ve (d) 'yi zorlaştırır (ancak not imkansız değildir). Kıvırcık parantez kullanmanın (a) üzerinde etkisi olmadığını söyleyebilirim.

Kıvırcık ayraçın sunduğu netliği tercih ederim. Tam olarak ne anlama geldiğini biliyorsunuz ve birinin sadece goofed ve bırakıp bırakmadığını (ve bir hata getirdiğini) tahmin etmek zorunda değilsiniz. Onları atladığım tek zaman, if ve eylemi aynı satıra koyduğum zamandır. Bunu da çok sık yapmıyorum. KER C benzeri programlamanın yıllardan beri, çizgiyi bir küme ayracı ile bitirmek IDE için zorlamıyorsa üstesinden gelmek için çalışmam gereken bir uygulama olsa da ben mi.

if (condition) action();  // ok by me

if (condition) // normal/standard for me
{
   action();
}

Bence üzerinde çalıştığınız proje ve kişisel zevkiniz için bir kurallar meselesi.

Aşağıdakiler gibi bazı durumlar dışında, genellikle ihtiyaç duyulmadığında bunları atlarım:

if (something)
    just one statement; // i find this ugly
else
{
    // many
    // lines
    // of code
}

tercih ederim

if (something)
{
    just one statement; // looks better:)
}
else
{
    // many
    // lines
    // of code
}

Bunun sizi ısıtabileceği örneklerden biri C / C ++ makrolarının eski günlerinde. Bunun bir C # sorusu olduğunu biliyorum, ancak genellikle kodlama standartları, standardın ilk etapta yaratılma nedenleri olmadan devam ediyor.

Makrolarınızı oluştururken çok dikkatli değilseniz, {} kullanmayan if ifadelerinde sorunlara neden olabilirsiniz.

#define BADLY_MADE_MACRO(x) function1(x); function2(x);

if (myCondition) BADLY_MADE_MACRO(myValue)

Şimdi, beni yanlış anlamayın, sadece C / C ++ 'da bu sorunu önlemek için her zaman {} yapmanız gerektiğini söylemiyorum, ama bu yüzden bazı garip hatalarla uğraşmak zorunda kaldım.

Ben de aynı şekilde düşünürüm.

Bir güne kadar (neden her zaman hayatınızı sonsuza dek değiştiren "bir gün" var?) 24-36 saat boyunca, üretim kodunda hata ayıklama yapmadan sadece birinin arama / değiştirme değişikliği ile birlikte parantez koymadığını öğrenmek için harcıyoruz .

Böyle bir şeydi.

 if( debugEnabled ) 
      println( "About to save 1 day of work to some very important place.");
 saveDayData();

Sonra gelen

 if( debugEnabled ) 
 //     println( "About to save 1 day of work to some very important place.");
 saveDayData();

Sistemin günlük 500 MB kütük ürettiği ortaya çıktı ve bizden durdurmamız istendi. Hata ayıklama bayrağı yeterli değildi, bu yüzden bir arama ve değiştirme println sırayla yapıldı.

Yine de uygulama üretime geçtiğinde hata ayıklama bayrağı kapalı ve önemli "saveDayData" asla çağrılmadı.

DÜZENLE

Şimdi kaşlı ayraçları kullanmadığım tek yer if / try yapıda.

if( object != null ) try { 
     object.close();
} catch( .....

Bir süperstar geliştiricisini izledikten sonra.

Künt olmak için şöyle görüyorum:

İyi programcılar defalarca program yapar, Kötü programcılar bunu yapmaz.

Yukarıdaki birkaç örnek ve parantez unutarak ilgili hatalarla kendi benzer deneyimlerim olduğundan, HER ZAMAN AĞIRLIKLARINIZIN zor yolunu öğrendim.

Başka bir şey kişisel tarzın güvenliğe göre seçilmesidir ve bu açıkça kötü bir programlamadır.

Joel bile bundan bahsediyor Yanlış Kodun Yanlış Görünmesinde

Bir kez eksik diş telleri nedeniyle bir hata olsun, eksik diş telleri yanlış görünüyor çünkü başka bir hata oluşması için potansiyel bir yer olduğunu biliyorum.

Şunlar için oldukça mutluyum:

foreach (Foo f in foos)
  foreach (Bar b in bars)
    if (f.Equals(b))
      return true;

return false;

Şahsen, nedenini anlamıyorum

foreach (Foo f in foos)
{
  foreach (Bar b in bars)
  {
    if (f.Equals(b))
    {
      return true;
    }
  }
}

return false;

artık daha okunabilir.

Evet, satırlar ücretsiz, ancak neden sayfaların yarısı ve kod sayfalarının yarısı büyüklüğünde olabiliyorsa kaydırmam gerekiyor?

Okunabilirlik veya bakımda bir fark varsa, o zaman, elbette, parantezleri koyun ... ama bu durumda herhangi bir neden görmüyorum.

Ayrıca, her zaman başka bir yerde yuvalanmışsa yuvalanmış için parantez koyacağım

if (condition1)
  if (condition2)
    doSomething();
  else (condition2)
    doSomethingElse();

vs

if (condition1)
  if (condition2)
    doSomething();
else (condition2)
  doSomethingElse();

çok kafa karıştırıcı, bu yüzden her zaman şöyle yazıyorum:

if (condition1)
{
  if (condition2)
    doSomething();
  else (condition2)
    doSomethingElse();
}

Mümkün olduğunda üçlü operatörler kullanıyorum, ama onları asla yuvalamıyorum .

"Birinin size kod yazması için ödeme yapmasını sağlayacak kadar zekiyseniz, kodun akışını görmek için yalnızca girintiye güvenmeyecek kadar zeki olmanız gerekir."

Ancak ... hatalar yapılabilir ve bu hata ayıklamak için bir acıdır ... özellikle başka birinin koduna bakmaya geliyorsan.

Felsefem kodu daha okunaklı kılıyorsa neden yapmıyorsunuz?

Açıkçası, kısa ve aşırı tanımlayıcı değişken isimleri arasındaki mutlu ortamı bulmak gibi bir yere çizgi çizmeniz gerekiyor. Ancak parantezler gerçekten hatalardan kaçınır ve kodun okunabilirliğini artırır.

Kodlayıcı olacak kadar zeki insanların, parantezsiz ifadelerden kaynaklanan hataları önleyecek kadar zeki olduklarını iddia edebilirsiniz. Ama dürüstçe, hiçbir zaman bir yazım hatası kadar basit bir şey tarafından açılmadığınızı söyleyebilir misiniz? Bunun gibi Minutia büyük projelere bakarken çok zor olabilir.

Her zaman istisnalar vardır, ancak parantezleri yalnızca formlardan birinde olduğunda atlamaya karşı çıkacağım:

if(x == y)
   for(/* loop */)
   {
      //200 lines
   }

//rampion's example:
for(/* loop */)
{
   for(/* loop */)
      for(/* loop */)
      {
         //several lines
      }
}

Aksi takdirde sorunum yok.

Bazen çok alt kodu (birden çok ifade kullanarak) kullanın, ama bunun dışında her zaman parantez koymak. Ben sadece kodu daha net yapar buluyorum. Açık bir ifadeyle, bir ifadenin bir bloğun bir parçası olduğu (ve muhtemelen bir if vb.nin bir parçası) olduğu açıktır.

Gördüm

if (...)
    foo();
    bar();

- böcek beni ısırmaya (Aslında hata tanıtmak etmedi doğrusu "beni ve arkadaşları") bir zamanlar . Bu, o zamanlar kodlama standartlarımızın her yerde parantez kullanılmasını önermesine rağmen oldu. Tespit etmem şaşırtıcı derecede uzun sürdü - çünkü ne görmek istediğini görüyorsun. (Bu yaklaşık 10 yıl önceydi. Belki şimdi daha hızlı bulurdum.)

Tabii ki "çizginin sonunda küme ayracı" kullanırsanız, ortaya çıkan fazladan satırları azaltır, ama ben yine de bu tarzı kişisel olarak sevmiyorum. (İş yerinde kullanıyorum ve beklediğimden daha az tatsız buldum, ama yine de biraz tatsız.)

Ben bilgisayar programlama bu alanda (sen çok) akranlarım tek satır blokları üzerinde parantez atlamak potansiyel hata olasılığı göz korkutmak etkilendim ve alçakgönüllülük.

Sanırım akıllı olmadığım anlamına geliyor. Bu konuda birçok kez hata yaptım. Bu konuda başkalarının hatalarını ayıkladım. Bu nedenle yazılım gemisini hatalarla izledim (VS2002 çalıştıran bir makineye RDP ve izleme penceresi yazı tipi sakat olacak).

Kodlama stilindeki bir değişiklikle önlenebilecek tüm hatalara bakarsam, liste çok uzundur. Bu vakaların her birinde yaklaşımımı değiştirmeseydim, muhtemelen hiçbir zaman bir programcı olarak yapmazdım. Yine sanırım akıllı değilim. Telafi etmek için, uzun zamandır tek satır bloklarda parantezin sadık bir kullanıcısıyım.

Bununla birlikte, dünyada "tek satır bloklarda parantez kullanacaksınız" kuralını bugün Musa'nın bize indirdiği zamandan daha az alakalı hale getiren bazı şeyler değişti:

• Bazı popüler diller, bilgisayarın programcı gibi girintiyi okumasını sağlayarak sorunu ortadan kaldırır (örn. Python).

• Editörüm benim için otomatik olarak biçimlendirildiğinden , girintiyle yanıltıcı olma şansım çok azaldı.

• TDD , tek satırlık bir blokla karıştırıldığım için bir hata verirsem, hatayı hızlı bir şekilde keşfetmem daha olasıdır.

• Yeniden düzenleme ve dil ifadesi , bloklarımın çok daha kısa olduğu ve tek satırlı blokların eskisinden çok daha sık olduğu anlamına gelir. Varsayımsal olarak, ExtractMethod'un acımasız bir uygulamasıyla, tüm programımda muhtemelen sadece tek satır blokları olabilir. (Bunun nasıl görüneceğini merak ediyorum?)

Aslında, tek satır bloklar üzerinde acımasızca yeniden düzenleme ve parantezleri atlamanın belirgin bir yararı olabilir: parantez gördüğünüzde, kafanızda "burada karmaşıklık! Dikkat!" Diyen küçük bir alarm çıkabilir. Bunun norm olup olmadığını düşünün:

if (condition) Foo();   // normal, everyday code

if (condition) 
{
    // something non-trivial hapening; pay attention!
    Foo();
    Bar();
}

Kendimi kodlama kuralımı "tek satırlı bloklarda asla parantez olmayabilir" veya "bloğu koşulla aynı satıra koyabilirseniz ve 80 karaktere sığarsa, kaşlı ayraçları atla ". Göreceğiz.

Üç sözleşmeden:

if(addCurleyBraces()) bugFreeSofware.hooray();

ve:

if(addCurleyBraces())
    bugFreeSofware.hooray();

ve (açılış ve kapanış ayracı kullanan herhangi bir girinti stilini temsil eder):

if(addCurleyBraces()) {
    bugFreeSofware.hooray();
}

Sonuncuyu şu şekilde tercih ederim:

• Tüm if ifadeleri aynı şekilde yazılmışsa okumayı daha kolay buluyorum.
• Yazılımı biraz daha sağlam ve hatasız hale getirebilir. Bununla birlikte, tüm modern IDE'ler ve gelişmiş metin editörleri, yorum biçimlendirmesini bozmadığı veya ekip standartlarına aykırı olmadığı sürece herkesin kullanması gerektiğini düşündüğüm güzel otomatik girintili özelliklere sahiptir (çoğu durumda özel bir biçimlendirme şeması oluşturmak mümkündür) ve ekiple paylaşın). Demek istediğim, girintinin doğru yapılması durumunda hata girişi riskinin biraz azalması.
• Boole ifadesinin ve ifadelerinin farklı satırlarda yürütülmesini tercih ederim. Hata ayıklama amacıyla bir satırı işaretlemeyi seviyorum. Bir deyimi işaretleyip ona adım atabileceğim bir IDE kullanıyorsam bile, bu etkileşimli bir işlemdir ve hata ayıklamaya başladığımı unutabilirim ya da en azından birkaç kod boyunca adım atmam biraz zaman alacak (hata ayıklama sırasında her seferinde konumu manuel olarak işaretlemem gerektiğinden).

Diş telleri kullanmayla ilgili temel argümanlarınız ek satırlar kullanmaları ve ek girinti gerektirmeleri.

Satırlar (neredeyse) ücretsizdir, kodunuzdaki satır sayısını en aza indirmek objektif olmamalıdır.

Ve girinti, ayraç kullanımından bağımsızdır. Basamaklı 'kullanma' örneğinizde, parantezleri atlasanız bile onlara girintili olmanız gerektiğini düşünüyorum.

Düzenli ve özlü kod yazarken güçlü bir inancım, ama her zaman kıvırcık parantez kullanırdım. Hızlı bir şekilde belirli bir kod satırı var kapsamını görmek için uygun bir yol olduğunu bulmak. Belirsizlik yok, sadece önünüzde beliriyor.

Bazıları bunun bir tercih örneği olduğunu söyleyebilir, ancak bir programın mantıksal akışını dahili olarak tutarlıysa takip etmeyi çok daha kolay buluyorum ve böyle bir IF ifadesi yazmanın tutarlı olduğuna inanmıyorum;

if(x < y)
    x = y;
else
    y = x;

Ve bunun gibi bir başkası;

if(x < y)
{
    x = y;
    x++;
}
else
{
    y = x;
    y++;
}

Sadece bir genel stil seçip ona sadık kalmayı tercih ederim :)

Ana konulardan biri, kontrol ifadesinden ( for, neyiniz ifvar) ve ifadenin sonundan ayrı olarak, tek astarlı ve tek olmayan astar bölgelerine sahip olmanızdır.

Örneğin:

for (...)
{
  for (...)
    for (...) 
    {
      // a couple pages of code
    }
  // which for block is ending here?  A good text editor will tell you, 
  // but it's not obvious when you're reading the code
}

Eskiden "kıvırcık parantez bir zorunluluktur!"

if (foo)
    snafu();
    bar();

İyi birim testleri ile, okunabilirliği geliştirmek için basit ifadeler için kıvırcık parantezleri güvenle çıkarabilirim (evet, bu öznel olabilir).

Alternatif olarak, yukarıdaki gibi bir şey için, muhtemelen şöyle görünmesini isterim:

if (foo) snafu();

Bu şekilde, koşula bar () eklemesi gereken geliştirici, kıvırcık parantez eksikliğini tanımaya ve eklemeye daha yatkın olacaktır.

Bazı kişisel yargıları kullanın.

if (foo)
  bar();

tek başına iyidir. Daha sonra böyle bir şey koyarak moronlar hakkında gerçekten endişelenmedikçe:

if (foo)
  bar();
  baz();

Moronlar hakkında endişelenmiyorsanız, iyisiniz (ben - temel kod sözdizimini doğru şekilde alamazlarsa, bu sorunlarının en azıdır)>

Buna karşılık, çok daha okunabilir.

Kalan zaman:

if (foo) {
  bar();
  baz();
}

Hatırlayabildiğim sürece bu benim favorim oldu. Bunlara ek olarak:

if (foo) {
  bar();
  baz();
} else {
  qux();
}

Benim için çalışıyor.

Dikey alan tek başına çok alakalı değil, okunabilirlik. Bir satırdaki açılış ayracı, gözünüz bir sonraki satıra geçene kadar sözdizimsel bir elemanın konuşmasını durdurur. Sevdiğim gibi değil.

Tamam, bu ölüme cevaplanan eski bir soru. Ekleyecek bir şeyim var.

Öncelikle şunu söylemeliyim: KIRMIZI KULLANIN. Sadece okunabilirliğe yardımcı olabilirler ve montaj yazmadığınız sürece okunabilirlik (kendiniz ve diğerleri için!) Öncelik listenizde çok yüksek olmalıdır. Her zaman okunamayan kod, her zaman hatalara yol açar. Parantezlerin kodunuzun çok fazla yer kapladığını görürseniz, yöntemleriniz muhtemelen çok uzundur. Doğru şekilde yapıyorsanız, herhangi bir yöntemin çoğu veya tümü bir ekran yüksekliğine sığmalıdır ve Bul (F3) arkadaşınızdır.

Şimdi benim eklemem için: Bununla ilgili bir sorun var:

if (foo) bar();

Yalnızca bar () çalışacaksa vurulacak bir kesme noktası ayarlamayı deneyin. Bunu, C # 'da imleci kodun ikinci yarısına koyarak yapabilirsiniz, ancak bu açık değildir ve biraz acıdır. C ++ ile hiç yapamadınız. C ++ kodu üzerinde çalışan en üst düzey geliştiricilerimizden biri, 'if' ifadelerini bu nedenle iki satıra ayırmakta ısrar ediyor. Ve ona katılıyorum.

Öyleyse bunu yapın:

if (foo)
{
    bar(); //It is easy to put a breakpoint here, and that is useful.
}

parantezli kodun çok fazla yer kaplamasını önlemek için, Kod Tamamlandı kitabında önerilen tekniği kullanıyorum :

if (...) {
    foo();
    bar();
}
else {
    ...
}

Diyelim ki bazı kodlarınız var:

if (foo)
    bar();

ve sonra başka biri gelir ve ekler:

if (foo)
    snafu();
    bar();

Yazılma şekline göre, bar (); artık koşulsuz yürütüldü. Kıvırcık parantezleri ekleyerek, bu tür bir yanlışlıkla hatayı önlersiniz. Kod, bu tür hataların yapılmasını zorlaştıracak veya imkansız hale getirecek şekilde yazılmalıdır. Bir kod incelemesi yapıyordum ve özellikle birden çok satıra yayılan eksik parantezleri görürsem, bir kusur yaratacağım. Gerekçelendirildiği durumlarda, böyle bir hata yapma şansının tekrar minimumda tutulması için bir satırda tutun.

Çizgileri azaltmak gerçekten diş telleri bırakmak için iyi bir argüman değildir. Metodunuz çok büyükse, muhtemelen daha küçük parçalara dönüştürülmeli veya yeniden yapılandırılmalıdır. Bunu yapmak şüphesiz okunabilirliği basitçe parantez çıkarmaktan daha fazla artıracaktır.

İlk örneğiniz gibi, uygun olduğunda onları her zaman atlarım. Bakarak görebildiğim ve anlayabildiğim temiz, özlü kod Kaydırma ve satır satır okumak zorunda olduğum koddan daha kolay bakım, hata ayıklama ve anlama daha kolaydır. Bence çoğu programcı buna katılıyor.

Birden fazla yuvalama, if / else cümleleri vb. Yapmaya başlarsanız elden çıkması kolaydır, ancak çoğu programcının çizgiyi nerede çizeceğini söyleyebileceğini düşünüyorum.

Ben argüman gibi tür görmek if ( foo == 0 )vs if ( 0 == foo ). İkincisi, yeni programcıların hatalarını önleyebilir (ve hatta bazen gaziler için), birincisi kodu korurken hızlı bir şekilde okumak ve anlamak daha kolaydır.

Çoğu zaman bir şirket veya bir FOSS projesi için bir kodlama standardı olarak yerleşir.

Sonuçta bir başkasının kodunuzu alması gerekir ve her geliştiricinin üzerinde çalıştıkları kod bölümünün belirli stilini bulmak zorunda kalması büyük bir zaman kaybıdır.

Ayrıca, birisinin günde bir kereden fazla Python ve bir Cish dili arasında gittiğini düşünün ... Python'da girintileme, dilin blok sembolünün bir parçasıdır ve teklif ettiğiniz gibi bir hata yapmak oldukça kolay olacaktır.

Err daha güvenli tarafında - sadece bir hata daha potansiyel olarak düzeltmek zorunda kalmayacaksınız.

Tüm bloklarım kıvrımlara sarılırsa kişisel olarak daha güvende hissediyorum. Tek satırlar için bile, bunlar hataları kolayca önleyen basit gösterimlerdir. Bloğun gövdesini, bloğun gövdesini bloğun dışındaki aşağıdaki ifadelerle karıştırmamak için blokta ne olduğunu açıkça görmeniz açısından kodu daha okunabilir hale getirir.

Bir astarım varsa, genellikle aşağıdaki gibi biçimlendiririm:

if( some_condition ) { do_some_operation; }

Çizgi çok hantalsa aşağıdakileri kullanın:

if( some_condition )
{
    do_some_operation;
}