it-swarm-tr.com

Operatörden önce / sonra satır sonu

Sun'ın Java kod kuralı, operatörün önüne satır sonu koymayı önerirken, diğer pek çok yönerge de aynı fikirde değil. bir diğeri?

String longVarName = a + b + c + d +
          e + f;

vs

String longVarName = a + b + c + d
          + e + f;
31
Nutel

Tek bir satırda bırakmayı ve niyeti ortaya çıkaran değişken adları (ve işlevleri) açısından okunabilirliği düşünürdüm.

Dağınık hale geldiğinde refactor:

  • değişkenleri yeniden adlandır
  • yeni değişkenleri/fonksiyonları tanıtmak

Misal

subtotal = price * (100 + tax_ratio) / 100

vs.

tax = price * tax_ratio / 100
subtotal = price + tax
16
Kamil Tomšík

Normalde en çok kullanılan stil yönergelerini veya belirli bir kodlama standart araçlarını izlerim. Yaygın olarak kullanılan bir stili kullanmanın avantajı, başkalarının kodlarını okurken veya bir stil yönergelerinin ayarlandığı açık kaynaklı bir projede yer aldığınızda faydalar sağlar.

Gördüğüm en yaygın stiller, sorudaki ikinci stildir. Bunların listesi için aşağıya bakın:

Google Stil Kılavuz :

Atama dışı bir operatörde bir çizgi kesildiğinde, kesme sembolün önüne gelir.

Güneş Kodlama Sözleşmesi :

Bir operatörden önce mola

Checkstyle Operator Wrap kontrolü 's varsayılan değer nl:

Operatör yeni bir hatta olmalıdır

37
ceilfors

Okunabilirliğin bir argüman olduğunu hayal edebiliyorum

result = longidentifier +
   short -
   alittlelonger -
   c;

versus

result = longidentifier
   + short
   - alittlelonger
   - c;

İkinci örnekte operatörler güzel sıralanmıştır ve değişkenin hangi işaretle denkleme girdiğini kolayca görebilirsiniz. Bence bu ikili operatörler için de bir anlam ifade ediyor ama destekleme vb. İle daha net olan her şeyi yapmalısınız.

37

Kodda ben operatör sonra mola eğilimindedir:

foo = some_long_expression() +
      some_other_long_expression();

Burada bir satırın sonundaki sarkan operatör, kodun devam ettiği okuyucu için büyük bir ipucu. Açıklama sonlandırıcısı olmayan dillerde, sarkan operatör kodun devam ettiği derleyici/yorumlayıcı için yeterli bir ipucu görevi görebilir (aksi takdirde çirkin bir devam hattı yapısı kullanmak zorunda kalacağım).

Bu ifadeyi belgelendirirken (belgeleme gerekiyorsa), molayı operatörden önce koyma eğilimindeyim.

10
David Hammen

Çizginin, kırmak istediğiniz ifadenin ayrıştırma ağacındaki en yüksek sembolle başlaması gerektiğine inanıyorum. İfadede en önemli operatörü vurgular. Önceki satırın sonuna değil, bir satırın başına başka bir öğe koymanızın nedeni de aynıdır.

Aşağıdaki örnekte, sol kenar boşluğunu tararken, ifadenin yapısını OR/3 ifade olarak) görürsünüz.

if (ch>='A' && ch<='Z'
    || ch>='a' && ch<='z'
    || ch>='0' && ch<='9')
{...}

Aşağıda || operatörler daha az vurgulanır. Daha az belirgin bir || ifadeler. Özellikle çizgiler farklı uzunluklarda olsaydı.

if (ch>='A' && ch<='Z' ||
    ch>='a' && ch<='z' ||
    ch>='0' && ch<='9')
{...}

Ve sadece referans için, bu çok yanlış. || operatörler hiç vurgulanmaz.

if ( ch>='A' && ch<='Z' || ch>='a'
     && ch<='z' || ch>='0' && ch<='9')
{...}

Hatta bunu nadiren görsem de, satırın başına virgül koymayı severim. Bunu paylaşılan kodda yapmaktan kaçınırım.

var note:Object =
    { key: key
    , type: 'P'
    , text: someLongProcedureCallGettingTheUserInitials()
       + ": " + getTheTextThatWasTyped()
    };
3
Florian F

Tutarlı kaldığınız sürece, her iki şekilde de gerçek bir avantaj olmadığını bilin. Bu özellikle kod birleştirme ve beyaz boşluk dikkate alındığında önemlidir.

3
Martijn Verburg

Uzun aritmetik denklemler için tipik olarak iki şeyden birini yaparım.

her şeyi tek bir satırda bırak:

foo = bar + baz - fizz + buzz + alpha - beta;

Ben tipik olarak sadece toplama ve çıkarma içeren denklemler için bunu yapmak, ben ciddi bir operatörün kapsamı berbat olabilir çarpma ve bölme ile bir yazım hatası yapmak bulabilirsiniz.

kullandığım ikinci biçim ilerici işleçler:

foo = bar;
foo += baz;
foo -= fizz;
foo += buzz;
foo /= alpha - beta;
foo *= spiff;

Performansı gözle görülür bir şekilde geliştirdiği kanıtlanmadıkça, tek bir hatta kısaltmak için hiçbir neden göremiyorum. Ayrıca, neler olup bittiğine dair bir belirsizlik yoktur ve / Ve * Operatörleri için bir parantezin yanlış yerleştirilme şansı daha azdır.

2
zzzzBov

Birleştirme karakterini (veya herhangi bir operatörü) satırın başına yerleştirmek okunabilirliği artırır. Her satırın başına odaklanarak kodu tararız. Bir satır bir işleçle başladığında, okuyucu bir karakteri tarayarak satırın önceki ifadenin devamı olduğunu söyleyebilir.

Uzun matematiksel ifadeler her zaman dizgindir, böylece her yeni satır bir işleçle başlar. Kodun bu sözleşmeye uymaması için hiçbir neden yoktur.

2
kevin cline

İfadeyi bir satırda bırakın ve çok uzun olursa, daha küçük ifadelere bölün:

days = ((year * months_per_year) + month) * days_per_month + day

dönüşür:

months = year * months_per_year + month
days = months * days_per_month + day

Bu mümkün değilse, operatörden önce kırılmayı daha okunabilir buluyorum ve operatörün bir önceki atamanın hemen altına başlamasını sağladım (değişkenin altına koymak beni düşünmek ve tekrarlamak zorunda bırakıyor, ki bu hedef daha kolay okunmasını sağlamaktır):

random = years * months_per_year 
         + month * days_per_month 
         + day * hours_per_day 
         + hour * minutes_per_hour 
         + minute * seconds_per_minute 
         + second
0
Joel