Neden “eğer öyleyse” ifadeleri neredeyse hiç tablo biçiminde değildir?

if   i>0 : return sqrt(i)  
elif i==0: return 0  
else     : return 1j * sqrt(-i)

VS

if i>0:  
   return sqrt(i)  
elif i==0:  
   return 0  
else:  
   return 1j * sqrt(-i)  

Given the above examples, I don't understand why I virtually never see the first style in code bases. To me, you turn the code into a tabular format that shows clearly what you want. First column can virtually be ignored. Second column identifies the condition and the third column gives you the output you want. It seems, at least to me, straight-forward and easy to read. Yet I always see this simple kind of case/switch situation come out in the extended, tab indented format. Why is that? Do people find the second format more readable?

Bunun sorunlu olabileceği tek durum, kodun değişip uzaması. Bu durumda, kodu uzun, girintili formata yeniden yerleştirmenin tamamen makul olduğunu düşünüyorum. Herkes bunu ikinci yoldan mı yapıyor, çünkü her zaman olduğu gibi mi? Şeytanın avukatı olmak, sanırım başka bir neden, insanların kafa karıştırıcı if / else ifadelerinin karmaşıklığına bağlı olarak iki farklı biçim bulmaları olabilir. Herhangi bir fikir takdir edilecektir.

Bunun bir nedeni, popüler olduğu dilleri kullanmamanız olabilir.

Birkaç karşı örnek:

Muhafızlarla ve desenlerle Haskell:

sign x |  x >  0        =   1
       |  x == 0        =   0
       |  x <  0        =  -1

take  0     _           =  []
take  _     []          =  []
take  n     (x:xs)      =  x : take (n-1) xs

Desenli Erlang:

insert(X,Set) ->
    case lists:member(X,Set) of
        true  -> Set;
        false -> [X|Set]
    end.

Emacs Lisp:

(pcase (get-return-code x)
  (`success       (message "Done!"))
  (`would-block   (message "Sorry, can't do it now"))
  (`read-only     (message "The shmliblick is read-only"))
  (`access-denied (message "You do not have the needed rights"))
  (code           (message "Unknown return code %S" code)))

Genel olarak, tablo formatının işlevsel diller (ve genel olarak ifadeye dayalı diller) arasında oldukça popüler olduğunu, satırları kesmenin ise diğerlerinde en popüler olduğunu (çoğunlukla ifade tabanlı) görüyorum.

Daha okunaklı. Bunun birkaç nedeni:

• Neredeyse her dil bu sözdizimini kullanır (hepsi değil, çoğu - örneğin Python gibi görünüyor)
• isanae , çoğu hata ayıklayıcısının satır tabanlı olduğunu (açıklama temelli değil) yorumunda belirtti.
• Noktalı virgül veya parantez içine almak zorunda kalırsanız daha çirkin görünmeye başlar
• Yukarıdan aşağıya daha sorunsuz okur
• Önemsiz iade ifadelerinden başka bir şeyiniz varsa korkunç derecede okunaksız görünüyor
  • Koşullu kod artık görsel olarak ayrı olmadığından kod girmediğinizde girintili anlamlı sözdizimi kaybolur ( Dan Neely'den )
  • Bu, özellikle ifadeleri 1 satırına öğe eklemeye / eklemeye devam ederseniz kötü olacaktır
• Sadece eğer tüm çekleriniz aynı uzunluktaysa okunabilir
• Bu ifadeler, çok satırlı ifadeler halinde ifadelerin oneliner olması gerektiğine göre karmaşık bir biçimde biçimlendirilemeyeceğiniz anlamına gelir
• Satır satır dikey olarak okurken, birden fazla satırı birlikte ayrıştırmaya çalışmadığımda hataları / mantık akışını farketme ihtimalim çok daha fazla
• Beyinlerimiz daha dar, uzun metinleri, uzun metinlerden çok daha hızlı okur

Bunlardan herhangi birini yapmaya çalıştığınız an, çok satırlı ifadelere yeniden yazmanız gerekecek. Bu sadece zamanını boşa harcadığın anlamına geliyor!

Ayrıca insanlar kaçınılmaz olarak şöyle bir şey ekler:

if i>0:  
   print('foobar')
   return sqrt(i)  
elif i==0:  
   return 0  
else:  
   return 1j * sqrt(-i)  

Bu formatın, alternatifinizden çok daha iyi olduğuna karar vermeden önce bunu yapmanız çok sık olmaz. Ah, ama hepsini bir satırda sıraya sokabilirsin! enderland içten ölür .

Veya bu:

if   i>0 : return sqrt(i)  
elif i==0 and bar==0: return 0  
else     : return 1j * sqrt(-i)

Bu gerçekten, gerçekten sinir bozucu. Kimse böyle şeyleri biçimlendirmekten hoşlanmaz.

Ve son olarak, "sekmeler için kaç tane boşluk" sorunu olan kutsal savaşa başlayacaksınız. Ekranda bir tablo formatı olarak mükemmel şekilde ortaya çıkan şey, ayarlara bağlı olarak mayın üzerinde işlemeyebilir.

Okunabilirlik IDE ayarlarına bağlı olmamalıdır.

'Kod birçok kez okundu, az yazıldı - bu yüzden okunabilirlik çok önemli' diye inanan bir firmayım.

Başkalarının kodunu okuduğumda bana yardımcı olan anahtar şey, gözlerimin tanımak için eğitildiği 'normal' kalıpları izlemesidir. Girintili formu en kolay bir şekilde okuyabilirim çünkü onu neredeyse otomatik olarak kaydettirecek kadar çok gördüm (benim açımdan çok az bilişsel çaba ile). 'Güzel' olduğu için değil - alışkın olduğum kuralları takip ediyor çünkü. Kongre 'daha iyi' atıyor ...

Bahsedilen diğer dezavantajların yanı sıra, tablo düzeni sürüm kontrolü birleştirme çatışmalarını el ile müdahale gerektiren ihtimalleri arttırmaktadır.

Bir sekmeli olarak işaretlenmiş kod bloğunun yeniden hizalanması gerektiğinde, sürüm kontrol sistemi bu satırların her birine değiştirilmiş olarak davranır:

diff --git a/foo.rb b/foo.rb
index 40f7833..694d8fe 100644
--- a/foo.rb
+++ b/foo.rb
@@ -1,8 +1,8 @@
 class Foo

   def initialize(options)
-    @cached_metadata = options[:metadata]
-    @logger          = options[:logger]
+    @metadata = options[:metadata]
+    @logger   = options[:logger]
   end

 end

Şimdi bu arada, başka bir dalda, bir programcının hizalanmış kod bloğuna yeni bir satır eklediğini varsayalım:

diff --git a/foo.rb b/foo.rb
index 40f7833..86648cb 100644
--- a/foo.rb
+++ b/foo.rb
@@ -3,6 +3,7 @@ class Foo
   def initialize(options)
     @cached_metadata = options[:metadata]
     @logger          = options[:logger]
+    @kittens         = options[:kittens]
   end

 end

O şubeyi birleştirmek başarısız olur:

wayne@mercury:/tmp/foo$ git merge add_kittens
Auto-merging foo.rb
CONFLICT (content): Merge conflict in foo.rb
Automatic merge failed; fix conflicts and then commit the result.

Eğer değiştirilmekte olan kod sekmeli sıralama kullanmasaydı, birleştirme otomatik olarak başarılı olurdu.

(Bu cevap, koddaki sekme uyumunu engelleyen kendi makalemden "intihal edildi" ).

Her şey belirtilen genişliğe sığarsa, tabular formatlar çok hoş olabilir. Bununla birlikte, bir şey tahsis edilen genişliği aşarsa, o zaman ya tablonun geri kalanıyla dizilmiş olmayan bir kısmına sahip olmak ya da tablonun içindeki diğer her şeyin düzenini uzun öğeyle uyuşacak şekilde ayarlamak gerekli olur. .

Kaynak dosyalar, tablo biçimindeki verilerle çalışmak üzere tasarlanan programlar kullanılarak düzenlenmişse ve daha küçük bir yazı tipi boyutu kullanarak çok uzun öğeleri işleyebilir, bunları aynı hücre içinde iki satıra böler vb. daha sık biçimlendirir, ancak çoğu derleyici, biçimlendirmeyi sürdürmek için bu tür düzenleyicilerin depolaması gereken biçimlendirme türlerinden arınmış kaynak dosyaları ister. Değişken miktarlarda girinti içeren ancak başka bir düzen bulunmayan çizgiler kullanmak, en iyi durumda tablo biçimlendirme kadar iyi değildir, ancak en kötü durumda neredeyse hiç sorun yaratmaz.

Özel durumlar için bu tür bir şey sağlayan 'switch' ifadesi var, ama sanırım sorduğun şey bu değil.

Tablo biçiminde ifadeler olup olmadığını gördüm, ancak bunu değerli kılmak için çok sayıda koşulun olması gerekiyor. 3 İfadeler en iyi şekilde geleneksel biçimde gösterilirse, ancak 20 yaşınız varsa, bunları daha net hale getirmek için biçimlendirilmiş büyük bir blokta görüntülemek çok daha kolaydır.

Ve işte nokta: netlik. Görmeyi kolaylaştırırsa (ve ilk örneğinizin: sınırlayıcının nerede olduğunu görmek kolay değildir), duruma göre biçimlendirin. Aksi takdirde, tanımak her zaman daha kolay olduğu için insanların beklediğine bağlı kalın.

İfadeniz gerçekten bu kadar kolaysa, çoğu programlama dili aşağıdakileri sunar:: branching operator:

return  ( i > 0  ) ? sqrt( i)
      : ( i == 0 ) ? 0
        /* else */ : 1j * sqrt( -i )

Bu kısa bir okunabilir tabular formatıdır. Ancak önemli olan kısım: Bir bakışta "büyük" eylemin ne olduğunu görüyorum. Bu bir iade ifadesidir! Ve değere belli koşullar tarafından karar verilir.

Öte yandan, farklı kodlar uygulayan şubeleriniz varsa, bu blokları girintilemek için daha okunaklı buluyorum. Çünkü şimdi if-ifadesine bağlı olarak farklı "büyük" eylemler var. Bir durumda fırlatırız, bir durumda log tutarız ve geri döneriz veya geri döneriz. Mantığa bağlı olarak farklı bir program akışı vardır, bu nedenle kod blokları farklı dalları kaplar ve geliştirici için daha belirgin hale getirir (örn. Program akışını kavramak için bir fonksiyonun hızlı okunması)

if ( i > 0 )
{
    throw new InvalidInputException(...);
}
else if ( i == 0 )
{
    return 0;
}
else
{
    log( "Calculating sqrt" );
    return sqrt( -i );
}

Enderland'ın daha önce de söylediği gibi, eylem olarak sadece bir "geri dönüşünüz" olduğunu ve bu "geri dönüşü" durumun sonuna doğru etiketleyebileceğinizi varsayıyorsunuz. Bunun neden başarılı olamayacağına dair bazı detaylar vermek istiyorum.

Tercih ettiğiniz dillerin ne olduğunu bilmiyorum, ancak C'yi uzun zamandır kodluyorum. İlk kodlamada veya daha sonraki bakım sırasında hatalara açık kod yapılarına izin vermeyerek bazı standart kodlama hatalarından kaçınmayı hedefleyen bir dizi kodlama standardı vardır. MISRA-C'ye en çok aşinayım, ancak başkaları da var ve genel olarak hepsinin kuralları aynı çünkü aynı dilde aynı sorunları ele alıyorlar.

Kodlama standartlarını sıklıkla gideren popüler hatalardan biri şu küçük hata: -

if (x == 10)
    do_something();
    do_something_else();

Bu, düşündüğünüzü yapmaz. C söz konusu olduğunda, eğer x 10 ise, onu çağırırsınız do_something(), ama sonra x'in değeri ne olursa olsundo_something_else() çağrılır . Yalnızca "if" ifadesinin hemen ardından gelen işlem şartlıdır. Bu kodlayıcının amaçladığı olabilir, bu durumda bakımcılar için potansiyel bir tuzak vardır; ya da kodlayıcının tasarladığı şey olmayabilir, bu durumda bir hata var. Bu popüler bir röportaj sorusu.

Kodlama standartlarındaki çözüm, tek satırlı olsalar bile tüm koşullu eylemlerin etrafına parantez koymaktır. Şimdi anlıyoruz

if (x == 10)
{
    do_something();
    do_something_else();
}

veya

if (x == 10)
{
    do_something();
}
do_something_else();

ve şimdi düzgün çalışıyor ve bakımcılar için açık.

Bunun tablo tarzı biçiminizle tamamen uyumlu olmadığını fark edeceksiniz.

Diğer bazı diller (örn. Python) bu soruna baktı ve kodlayıcıların mizanpajı netleştirmek için boşluk kullandığı için parantez yerine boşluk kullanmanın iyi bir fikir olacağına karar verdi. Yani Python'da

if x == 10:
    do_something()
    do_something_else()

hem çağrı yapan do_something()ve do_something_else()buna, x == 10 şartına

if x == 10:
    do_something()
do_something_else()

bunun yalnızca do_something()x'e bağlı olduğu ve do_something_else()her zaman denildiği anlamına gelir .

Bu geçerli bir konsepttir ve onu kullanmak için birkaç dil bulacaksınız. (Onu ilk önce Occam2'de gördüm.) Yine de, tablo tarzı biçiminizin diline uymadığını kolayca görebilirsiniz.

Tablo düzeni, birkaç sınırlı durumda yararlı olabilir, ancak if ile kullanışlıdır.

Basit durumlarda?: Daha iyi bir seçim olabilir. Orta durumlarda, bir anahtar genellikle daha uygun olur (eğer dilinizde varsa). Karmaşık durumlarda, çağrı masalarının daha uygun olduğunu görebilirsiniz.

Yeniden düzenleme yaptığım kod yeniden düzenlenirken, onu açıkça belli etmek için sekmeli hale getirdiğim birçok kez oldu. Nadiren bu şekilde bırakmamın bir nedeni, çoğu durumda sorunu anladıktan sonra çözmenin daha iyi bir yolu olabilir. Bazen bir kodlama uygulaması veya düzen standardı bunu yasaklar, bu durumda bir yorum faydalı olur.

Hakkında bazı sorular vardı ?:. Evet, bu üçlü operatördür (ya da eğer değerini düşünmeyi sevdiğim gibi). ilk bakışta, bu örnek için biraz karmaşık:: (ve fazla kullanım?: okunabilirliğe yardım etmiyor, ancak onu incitiyor), ancak bazı düşüncelerle örnek aşağıdaki gibi yeniden düzenlenebilir, ancak bu durumda bir anahtarın en okunaklı olduğunu düşünüyorum çözüm.

if i==0: return 0
return i>0?sqrt(i):(1j*sqrt(-i))

Tablo biçiminde yanlış bir şey görmüyorum. Kişisel tercih, ancak böyle bir üçlü kullanırım:

return i>0  ? sqrt(i)       :
       i==0 ? 0             :
              1j * sqrt(-i)

returnHer seferinde tekrar etmenize gerek yok :)