it-swarm.dev

Kodunuzda boş satırları nasıl kullanıyorsunuz?

Kıvırcık parantez yerleşimleri hakkında zaten tartışılan beyaz boşluk hakkında birkaç açıklama var.

Ben kendimi "mantıksal" gruplarda birlikte gitmek şeyler ayırmak ve umarım bir sonraki kişinin az önce ürettiğim kodu okumak için gelmesini kolaylaştırmak amacıyla boş satırları ile kod serpin eğilimindedir.

Aslında, kodumu yazdığım gibi yapılandırdığımı söyleyebilirim: Birkaç satırdan (kesinlikle 10'dan kısa) daha uzun olmayan paragraflar yapıyorum ve her paragrafın kendi kendine yetmesini sağlamaya çalışıyorum.

Örneğin:

  • bir sınıfta, bir sonraki gruptan boş bir satırla ayırırken birlikte giden yöntemleri gruplayacağım.
  • bir yorum yazmam gerekirse, yorumdan önce boş bir satır koyacağım
  • bir yöntemde, işlemin her adımı için bir paragraf yaparım

Sonuçta, nadiren birlikte kümelenmiş 4/5 çok satır var, bu çok seyrek bir kod anlamına gelir.

Tüm bu beyaz alanı bir atık olarak görmüyorum çünkü aslında kodu yapılandırmak için kullanıyorum (aslında girintiyi kullandığım gibi) ve bu yüzden aldığınız ekran mülküne değer hissediyorum.

Örneğin:

for (int i = 0; i < 10; ++i)
{
    if (i % 3 == 0) continue;

    array[i] += 2;
}

İki ifadenin belirgin farklı amaçları olduğunu ve bu nedenle bunu açıkça ortaya koymak için ayrılmayı hak ettiğini düşünüyorum.

Peki, kodda boş satırları nasıl kullanıyorsunuz (ya da kullanmıyorsunuz)?

31
Matthieu M.

Her zaman

Boşluk, okunabilir kodu temizlemek için çok önemlidir. Boş bir satır (veya iki), mantıksal kod bloklarını görsel olarak ayırmaya yardımcı olur.

Örneğin, Steve McConnell'in Kodu Tamamlandı, İkinci Baskı Düzen ve Stil bölümünden:

Konular, programların hiç girintisi olmadığında iki ila dört boşluklu bir girintileme planına sahip olduklarında anlama testinde yüzde 20 ila 30 daha yüksek puan aldı. Aynı çalışma, bir programın mantıksal yapısını ne az vurgulamanın ne de fazla vurgulamanın önemli olduğunu bulmuştur. En düşük anlama puanları, hiç girintili olmayan programlarda elde edilmiştir. İkinci en düşük değere altı boşluklu girinti kullanılan programlarda ulaşıldı. Çalışma, iki ila dört boşluklu girintinin optimal olduğu sonucuna vardı. İlginç bir şekilde, deneydeki birçok denek, altı boşluklu girintinin, puanları daha düşük olmasına rağmen, daha küçük girintilerden daha kolay olduğunu hissetti. Muhtemelen altı boşluk girintisi hoş görünüyor. Ancak ne kadar güzel göründüğüne bakılmaksızın, altı boşluklu girinti daha az okunabilir hale gelir. Bu, estetik çekicilik ve okunabilirlik arasındaki bir çarpışma örneğidir.

87
Josh K

Açıklık için evet.

Tıpkı bu cevapta yaptığım gibi.

21
user2567

Yaparım ama koyarak belgelendirdiğimden emin olurum

(This line intentionally left blank.)

çizgide

13
Don

Evet, ama kötüye kullanmıyorum.

Bir yöntem içindeki kodun her satırı boş bir çizgi ile ayrılır ve mantıksal bir ayırma meydana geldiğinde iki boş satır kullanılır kod gördüm. Bu sadece bence daha az okunabilir kılıyor. Ayrıca boşluk gibi çılgın hizalamalar yapmak için kullanılır gördüm:

//Prot.   Return type                    Name                 Arg1        Arg2
//=====   ============================== ==================== =========== ========

private   int                            AMethodWithALongName(string s,   object o)
{
    ...
}

private   IDictionary<MyLongObject, int> SomethingCrazy      (string s)
{
    ...
}

protected void                           Foo                 (string str, object o)
{
    ...
}

Yatay boşlukların aynı şekilde kullanılması dikey boşluklara da uygulanabilir. Herhangi bir araç gibi, akıllıca kullanın.

12
Allon Guralnek

Ben tüm mümkün olduğunca açık kod yapmak için, ve boşluk genellikle bu çaba yararlı bir araçtır. Ama yeniden düzenlemeyi unutmayalım:

  • bir sınıfta, bir sonraki gruptan boş bir satırla ayırırken birlikte giden yöntemleri gruplayacağım.

Birkaç ilgili üyeniz olduğundan, bunlar yeni bir sınıfa adaydır.

  • bir yorum yazmam gerekirse, yorumdan önce genellikle boş bir satır koyacağım

Kod bir yorum istemek için yeterince net olmadığında, kodu yorum gerektirmeyecek kadar açık hale getirmek için refactor olup olmadığını soruyorum.

  • bir yöntemde, işlemin her adımı için bir paragraf yaparım

Neden her "paragraf" için bir yöntem yapmıyorsunuz?

Sınıfınızda bir grup yöntemle karşılaşırsanız, yeni bir sınıf çıkarma hakkındaki yukarıdaki notuma bakın.

5
Jay Bazuzi

Evet. Bir dosyayı görsel olarak taramayı kolaylaştırır. Diğer şeylerin yanı sıra, bir yorumun hangi satırla devam ettiğini de netleştirir.

Some code here
// Which line does this comment go with?
More code here

// It's pretty clear which line this comment goes with
More code here

Still more code here
5
Nathan Long

Kodumu bu şekilde yazmak için çok eleştirildim. Kimsenin bunu neden böyle yapmayacağını anlamıyorum.

Okunabilirlik uzun bir süre sonra bir projeye geri döndüğünüzde çok önemlidir ve "Bunu okuyan bir sonraki adam konumunuzu bilen bir Psikopatsa daima kod yazınız" ifadesini duydum.

5

Her zaman yazılım yazmam, ancak bunu yaptığımda netlik için boş satırlar kullanıyorum.

5
Trinidad

Boş satırları idareli ve tutarlı bir şekilde kullanıyorum ve sürekli idareli olmaktan çok daha önemli. Ancak:

  • Her kod satırı bir sonraki satırdan boş bir satırla ayrılırsa, çok fazla boş satır vardır.
  • Boş satırların yerleştirildiği yerde ne tekerleme ne de kolayca fark edilebilir bir şey varsa, o zaman bir dikkat dağıtıcıdır ve genellikle çok fazla vardır.
  • Bir işlev o kadar büyükse, birçok boş satıra ihtiyaç duyarsa, çok büyüktür.
  • Bir kod bloğunun öncesinde veya sonrasında birden fazla boş satıra ihtiyacı varsa, ciddi şekilde sapmış bir şey vardır.
  • İşlevler arasında ikiden fazla boş satırınız varsa, muhtemelen çok fazla boş satırınız vardır.

Bunların çoğu korkunç bir şekilde tartışmalı değil; sonra ne olabilir. Hattın sonunda açık ayraçlarla K&R gösteriminin iç karartıcı bir şekilde sık sık boş bir çizgi izlediğini not ediyorum. Şahsen satırın sonundaki parantezlerden hoşlanmıyorum ve küme ayracı notasyonun saçmalıklarını yaptıktan sonra boş bir çizgi ile karıştırıyorum (IMNSHO). Açık ayracı bir sonraki satıra, kendi başına koyun ve çoğunlukla boş bir satıra (ve IMNSHO, daha okunabilir bir kod) sahipsiniz. Çizginin sonunda K&R ayracı kullanmanız gerekiyorsa, dikey boşluğu fazla boş satırlarla boşa harcamayın.

// I don't like this
if (something == anotherthing) {
    print ...
    update ...
}

// I much prefer this
if (something == anotherthing)
{
    print ...
    update ...
}

// I loathe this - not least for its inconsistent spacing
if (something == anotherthing) {

    print ...
    update ...
}

// I loathe this too, for its absurd waste of vertical space
if (something == anotherthing) {

    print ...
    update ...

}
4
Jonathan Leffler

En okunaklı ve en az şaşırtıcı olanı yazın.

function validEmail($addr) {
    $regex = "/.../";   
    return preg_match($regex, $addr);
}

Bu işlev için 12 satırlık doktor yorumu gerekmez.

Aslında, herhangi bir yoruma ihtiyacı yoktur.

Veya boş satırlar.

Özünden uzaklaşırlardı.

3
KevBurnsJr

Fonksiyonun içinde mi? Nadiren

Farklı bir bloğum varsa, yeni bir işleve yeniden bakıyordur. Birkaç vaka buna değmezse.

Benim için işlevin içindeki boşluklar en yanlış "en iyi uygulamalardan" biridir.

3
Maniero

Bir keresinde, boş satırları kodum boyunca bolca serpirdim. Bugünlerde daha fazla koruma sağlama eğilimim var. Bence bu Steve Yegge'nin bahsettiklerinin bir parçası --- burada :

Umarım şimdiye kadar çizdiğim sahne neden bazen kodlara baktığınızı anlamanıza yardımcı olur ve hemen ondan nefret edersiniz. Eğer bir n00b iseniz, deneyimli koda bakacak ve modern yazılım mühendisliğinin temellerini hiç öğrenmemiş biri tarafından yazılan, aşılmaz, disiplinsiz bir saçmalık olduğunu söyleyeceksiniz. Eğer bir deneyimli iseniz, n00b koduna bakacaksınız ve bir stajyerin tek bir ağır içki gecesinde yazmış olabileceği aşırı yorumlanmış, süs tüyleri olduğunu söyleyeceksiniz.

Yapışma noktası sıkıştırma toleransıdır. Kariyeriniz boyunca kod yazarken, özellikle kod çok farklı dillere ve sorunlu alanlara yayılıyorsa, kod sıkıştırma toleransınız artar. Dev metin içeren çocuk kitaplarını okumaktan, daha küçük metin ve daha büyük kelimeler içeren giderek daha karmaşık romanlara kadar olan ilerlemeden farklı değil.

...

Sıkıştırma toleransı yüksek bir programcı, aslında bir hikaye anlatımı tarafından engellenir. Neden? Çünkü bir kod tabanını anlayabilmek için mümkün olduğunca çoğunu kafanıza paketleyebilmeniz gerekir. Bu karmaşık bir algoritma ise, deneyimli bir programcı ekranda her şeyi görmek ister, bu da boş satırların ve satır içi yorumların sayısını azaltmak anlamına gelir - özellikle kodun ne yaptığını tekrarlayan yorumlar. Bu bir n00b programcısının tam tersi. n00bs her seferinde tek bir ifadeye veya ifadeye odaklanmak, etrafındaki tüm kodu görünümden uzaklaştırmak ve böylece yüksek sesle bağırmak istiyor.

Ona esasen katılıyorum. Kodu sıkıştırmak çok daha iyidir, böylece bir ekranda mümkün olduğunca fazla alan elde etmek çok fazla yer kaplamaktan daha iyidir. Bu asla asla boş satır kullanmamalısınız. Sadece oluşturmaya çalıştığınız gruplama okunabilirliği son derece artırmazsa, yarardan çok zarar vermediğini düşünüyorum.

2
Jason Baker

Bir Profesör Emeritus İki Büyük Tavsiye Verdi

  1. Boşluk Ücretsiz
  2. Kağıdın önünden geçen zımba telleri kullanmayın, yoksa başarısız olurum.
2
Wonko the Sane

Sıklıkla

Benzer şekilde işlenen mantıksal kod blokları için kullanın. Farklı bir adım yaptığınızı göstermek için bir yorum ekledikten sonra, Ayıklama Yöntemi'nin zamanı geldi.

İyi Boşluk

{
    int x = computeX();
    x += ADJUSTMENT_FACTOR_X;

    int y = computeY();
    y += ADJUSTMENT_FACTORY_Y;

    setPosition(x, y);
}

Kötü Boşluk

{
    //Open a connection
    String serverAddress = lookupAddress();
    Connection connection = openConnection(serverAddress);
    connection.login(user, password);


    //Go get stuff from the server
    item1 = connection.get(1);
    item2 = connection.get(2);

    //Close connection
    connection.close();

    //log data
    log(item1);
    log(item2);

    //Update client
    gui.updateView(item1, item2);        
}    

vs

{
    Connection connection = openConnection();
    updateData(connection);
    closeConnection(connection);
    logUpdate();
    updateGui();
}

vs

{
     updateDataFromServer();
     logUpdate();
     updateGui();
}
2
Steve Jackson

Sadece boşluk kullanmıyorum, netlik için parantez kullanıyorum.

Bunların potansiyel olarak fonksiyonlar olabileceğini söylemek için kullandığım diş telleri.

code
{
    code
    code
    code
    code
}
{
    code
    code=code
    code
    code

    code()
    code()
}
2
user2528

Beyaz boşlukları paragraflama gibi düşünmeyi seviyorum. Bir fikre katkıda bulunan satırları gruplandırırsınız.

Yeni bir fikre veya aynı fikrin yeni bir yönüne başlıyorsanız, bunun gibi yeni bir paragraf başlatırsınız.

Zorunlu kodda, tek bir uyumlu görevi yerine getiren görevleri gruplandırırım; bildirim kodunda, bir fikrin tek bir tutarlı ifadesini tanımlayan kodu birlikte gruplandırıyorum.

Bunu açıkça İngilizce olarak yapmakta zorlanmıyorsunuz (bazı insanlar paragraflama ile korkunçtur), bu yüzden küçük bir uygulamada, aynı beceriyi kodlamaya uygulamak hiç de gergin olmamalıdır.

1
Rei Miyasaka

Boş satırlar bence bir zorunluluktur. Onları farklı mantıksal kod bloklarını ayırmak için kullanıyorum. Kodu okunabilir hale getirir. Okunabilir kod iyi koddur;)

İdeal kod parçam, her mantıksal bloğun boş bir çizgi ile ayrılması ve her bir bloğun üzerine büyük bir mantığı olan bir yorum olacaktır.

Tabii ki, eğer insanlar her yere birden fazla boş satır ekleyerek bunu yaparlarsa, onu çok rahatsız edici buluyorum :(

1
Karun AB

Ben sadece bir işlev/yöntem içindeki boşlukları bildirimleri ve kodu ayırmak için kullanın.

Bazı mantığı uygulayan kod alt bloklarını ayırmak için bazı satırlara ihtiyacınız olduğunu düşünüyorsanız, bunlar başka bir işlev/özel yöntemde olmalıdır. Bunu çok büyük bir ek yük yapmamak derleyicinize kalmış.

tipik olarak peusdo kodunda:

def function(arg1, argn, ...)
    INITIALIZERS

    CODE
    BLOCK_START
        INITIALIZERS

        CODE
    BLOCK_END
    CODE
end

Eğer işe yaramaz boşluk görürsem, genellikle boğulurum.

1
haylem

Benim başparmak kuralları şunlardır:

  1. Dün yazdığım kodu okumada sorun yaşıyorsam, muhtemelen bir veya üç yöntem çıkarmam gerekiyor.

  2. Sınıf tanımım kolayca okunacak kadar uzunsa, muhtemelen bir modül/arabirim/nesne ayıklamam gerekir.

  3. Yöntem tanımları: satır ekle

  4. Modül/Sınıf tanımları: iki satır ekle

1
philosodad

Evet. Okunabilirlik için. Bazen kodda boş satırları bile yazmadım. Ben boş satırları üzerinden mantıksal gruplama olduğunda kodu anlamak daha kolay - u üzerinden "hızlı okuma" gibi.

0
javacruiser

Bir mektup yazarken yaptığımız gibi kod blokları arasında boş satırlar kullanmalıyız.

Örneğin, bir döngüyü bitirdiğimizde işlevler arasında veya bir işlev içinde ...

İnsanlar üzerinde bakım yapmak zorunda kalırlarsa size temiz bir kod teşekkür edeceklerdir;)

0
user7242

Microsoft StyleCop tarafından önerilen beyaz boşluğu kullanıyoruz. Okunabilirlik ve tutarlılığın yanı sıra (küçük sınıf boyutlarıyla birlikte) düzgün bir şekilde yerleştirilmiş kodun, bir takımdaki çeşitli kişilerin aynı alanlarda çalıştığı zaman birleştirmeleri yönetmeyi çok daha kolay hale getirdiğini gördüm.

Sadece benim hayal gücüm olup olmadığından emin değilim ama farklı araçlar, düzgün bir şekilde düzenlendiğinde birleştirilirken eşdeğer kodun başladığı ve bittiği yeri tanımak için daha iyi bir iş yapıyor gibi görünüyor. Güzelce düzenlenmiş kod birleştirme sevinci. Tamam, bu bir yalandı - ama en azından acı yönetilebilir seviyelerde tutuldu.

0
FinnNk

Beyaz boşluk son derece değerlidir.

İşte anlaşma ... E = MC gibi karmaşık kod yazan nerds2 programlama becerilerini göstermek konusunda harikadır.

Şimdi altı ay ileri gidelim ve sabah 2:00 AM ve altı ay içinde bakılmayan sistem E = MC2. Bu hata ayıklamak neredeyse imkansız ... herkes korkuyor.

Kodun daha çok benzediğini varsayalım ...

See Dick
See Jane
See Dick and Jan

02:00 ise ve kod bozuksa. Hızlı bir bakış size üçüncü satırın

See Dick and Jane

Sorun çözüldü.

Alt satır ... boşluk kullanın.

Asla boş bir satır, tüm dosyada değil. Bu, kodda mola olmadığı anlamına gelmez:

 code;
 //
 morecode;

Boş satırlar kodun üzerinde çalışılacak bölümleri açmak içindir, düzenleyicinizde sizi önceki/sonraki boş satıra götürecek birkaç kısayol tuşunuz vardır.

0
Mark

Diğerlerinin belirttiği gibi, boş satırlar kodun daha kolay okunmasını sağlar. Ancak, bu standardı uygulayan bazı diller vardır. Başımın üstünden düşünebileceğim bir şey (boş çizgiler hakkında değil, doğru girinti hakkında) Python.

0
Skudd

Katılıyorum, boşlukları aynı şekilde kullanıyorum. Ancak, kendimi bir yöntemi çok fazla parçaya bölmek için boşluk kullanarak bulursam, bu kodu birden çok yönteme yeniden aktive etmem gerekebilir. Bir yöntemdeki çok fazla mantıksal bölüm, yöntemin test edilmesinin daha zor olacağını gösterebilir.

0
user7187

Onları mantıksal birimlere ayırmak için kullanıyorum. Boş satırlar kullanmayan çok az kod örneği gördüm, elbette şaşkınlık hariç.

0
kirk.burleson

Psikopat cevabı en iyisidir, ancak ben bunu bir sonraki kişinin aptal olduğunu ve sizin olduğunuzu varsayacaklarını ve yanlış olduğunu kanıtlamak isteyeceğinizi varsayarak değiştireceğim.

Okunabilirlik açısından da yorumların kullanılması önemlidir. Her bir işlevi veya altyordamı bir yorum bloğu ile açarım, açık metin, ne olduğunu, ne yaptığını, argümanların ne olduğunu ve beklenen sonuçların ne olduğunu (hata koşullarının bir listesi dahil) açıklar. O zaman ne yapılması ve/veya yapılması için tasarlandığı sorusu yoktur. Elde ettiği şey değişebilir, ancak bu daha da aşağı doğru ilerler.

Bence çok fazla kodlayıcı ya onlar olacağını varsayalım, kendileri kod üzerinde "onarım" yapacak, ya da sadece umurumda değil.

0
Peter

Boş satırlar önemlidir. Ancak, açılış ayracı üzerinde boş bir satırın boşa harcanması, bir taramada görebileceğiniz kod miktarını azaltır. Olmalı:

for (int i; i < 10; ++i)
{  if (i % 3 == 0) continue;

   array[i] += 2;
}

(Küme ayracı '{' ile 'için' aynı çizgiyi koymaya başlamayın ... bu meshuggah).

0
user7195