Beyaz alan hakkında, kaşlı ayraç yerleşimleri hakkında zaten tartışılan birkaç yorum yapıldı.

Ben kendim "mantıksal" gruplar halinde bir araya gelen şeyleri ayırma çabası içinde kodumu boş çizgilerle serpiştirmeye ve bir sonraki kişinin yeni ürettiğim kodu okumasını kolaylaştırmayı umuyorum.

Aslında, kodumu yazdığım gibi yapılandıracağımı söyleyebilirim: paragraf yapıyorum, birkaç satırdan uzun (kesinlikle 10'dan kısa değil) ve her paragrafı bağımsız hale getirmeye çalışıyorum.

Örneğin:

• Bir sınıfta, bir sonraki gruptan boş bir çizgiyle ayırırken, bir araya getirilen yöntemleri gruplayacağım.
• yorum yazmam gerekirse, yorumdan önce genellikle boş bir satır eklerim
• Bir yöntemde, işlemin her adımı için bir paragraf yapıyorum

Sonuçta, nadiren bir araya getirilmiş 4/5 satırdan oluşur, bu da çok seyrek bir kod anlamına gelir.

Tüm bu beyaz alanı boşa harcamıyorum, çünkü kodu yapılandırmak için kullanıyorum (aslında girintiyi kullandığım gibi) ve bu nedenle kullandığı ekran değerinde olduğunu düşünüyorum.

Örneğin:

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

    array[i] += 2;
}

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

Peki koddaki boş satırları gerçekte nasıl kullanıyorsunuz (veya kullanmıyorsunuz)?

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 Kod Tamamlandı, Düzen ve Stil hakkındaki İkinci Baskı bölümünden:

Programların hiç girintisi olmadığında, programların iki-dört boşluklu girinti düzenine sahip olduklarında, anlama testinde denekler yüzde 20 ila 30 daha yüksek puan aldı.Aynı çalışma, bir programın mantıksal yapısının altını çizmenin ya da altını çizmenin önemli olmadığını da ortaya koydu. Hiç bitmeyen programlarda en düşük anlama puanları elde edildi. İkinci en düşük altı boşluk girintisi kullanan programlarda sağlandı. Çalışma iki-dört-boşluk girintisinin optimal olduğu sonucuna varmıştır. İlginçtir ki, deneydeki birçok denek, altı boşluklu girintinin, puanları daha düşük olmasına rağmen, daha küçük girintilerden daha kolay kullanıldığını düşünüyordu. Muhtemelen altı boşluk girintisi hoş görünüyor çünkü. Ancak ne kadar hoş göründüğüne bakılmaksızın altı boşluk çentiklenmesinin daha az okunabilir olduğu ortaya çıkıyor. Bu, bir estetik çekicilik ve okunabilirlik arasında bir çarpışma örneğidir.

Netlik için evet.

Aynen bu cevapta yaptığım gibi.

Yaparım ama koyarak belgeledim

(This line intentionally left blank.)

çizgide

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

Bir yöntem içindeki her kod satırının boş bir satırla ayrıldığı ve mantıksal bir ayrılmanın gerçekleştiği iki boş satırın kullanıldığı kodu gördüm. Bu sadece benim görüşüme göre daha az okunabilir hale getirir. Ayrıca, bunun gibi çılgın ayarlamalar yapmak için kullanılan boşlukları da 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şluktaki aynı suiistimal dikey boşluklara da uygulanabilir. Herhangi bir araç gibi, akıllıca kullanın.

Kodumu bu şekilde yazdığım için çok eleştiriliyorum. Neden birisinin bu şekilde yapmayacağını anlamıyorum.

Okunabilirlik çok uzun bir süre sonra bir projeye geri döndüğünüzde çok önemli ve “Bunu okuyan bir sonraki kişi konumunuzu bilen bir Psikopatsa her zaman kod yaz” diyerek duydum.

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

Ben kodun mümkün olduğu kadar açık olmasını sağladım ve boşluklar bu işte genellikle yararlı bir araçtır. Ama yeniden düzenlemeyi unutmayalım:

• Bir sınıfta, bir sonraki gruptan boş bir çizgiyle ayırırken, bir araya getirilen yöntemleri gruplayacağım.

Birkaç ilgili üyeniz olduğundan, onlar yeni bir sınıfa adaylar.

• yorum yazmam gerekirse, yorumdan önce genellikle boş bir satır eklerim

Ne zaman kod bir yorum isteyecek kadar net değilse, yorum yapmak zorunda kalmayacak kadar açık bir kod oluşturabilmek için yeniden sorabilir miyim?

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

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

Sınıfınızda bir sürü yöntemle karşılaşırsanız, yeni bir sınıf çıkarmak için yukarıdaki notuma bakın.

Evet. Görsel olarak bir dosyayı taramayı kolaylaştırır. Diğer şeylerin yanı sıra, bir yorumun hangi çizgiyle gideceğini 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

Boş satırları düzenli ve tutarlı bir şekilde kullanıyorum ve sürekli olarak koruyucudan daha önemlidir. Ancak:

• Her kod satırı bir sonrakinden boş bir satıra ayrılırsa, çok fazla boş satır vardır.
• Ne kafiyen ne de boş satırların yerleştirildiği yer için kolayca fark edilebilecek bir sebep yoksa, o zaman dikkat dağıtıcıdır ve genellikle çok fazladır.
• Bir işlev çok fazla boş satıra ihtiyaç duyacak kadar büyükse, çok büyüktür.
• Bir kod bloğundan önce veya sonra birden fazla boş satır gerekiyorsa, ciddi şekilde yanlış giden bir şey vardır.
• İşlevler arasında ikiden fazla boş satır varsa, muhtemelen çok fazla boş satırınız vardır.

Bunların çoğu korkunç biçimde tartışmalı değil; aşağıdakiler olabilir. K&R notalarının satır sonundaki açık parantezlerle gösterilmesinin sık sık boş bir satır izlediğini not ediyorum. Ben şahsen satırın sonundaki parantezleri beğenmedim ve ayraçtan sonra notasyonu saçmalamadan sonra boş bir satır ile karıştırıyorum (IMNSHO). Açık köşeli ayracı bir sonraki satıra kendi başınıza koyun ve çoğunlukla boş bir satıra (ve IMNSHO, daha okunabilir kodlara) sahip olursunuz. Satırın sonunda K&R braketi kullanmanız gerekiyorsa, dikey boşluk tasarrufunu fazladan boş çizgilerle bükmeyin.

// 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 ...

}

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

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

Bu fonksiyon için 12 satır doktor yorumu gerekmez.

Aslında, herhangi bir yorum gerekmez.

Veya boş satırlar.

Özlerinden uzaklaşacaklardı.

Fonksiyonun içinde mi? Nadiren

Açıkça farklı bir bloğum varsa, yeni bir işleve yeniden yansıyor. Birkaç vaka buna değmezse.

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

sık sık

Benzer şekilde işlenen mantıksal kod blokları için kullanın. Farklı bir adım attığınızı göstermek için bir yorum eklediğinizde - Ayıklama Yöntemi zamanı.

İ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();
}

Sadece boşluk kullanmıyor, netlik için diş telleri kullanıyorum.

Bunları söylemek için kullandığım parantez potansiyel olarak fonksiyonlar olabilir.

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

    code()
    code()
}

Bir keresinde, kodum boyunca liberal olarak boş satırlar serpirdim. Bugünlerde daha fazla korunma eğilimindeyim. Bunun Steve Yegge'nin burada bahsettiği şeyin bir parçası olduğunu düşünüyorum :

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

Yapışma noktası, sıkıştırma toleransıdır. Kariyeriniz boyunca kod yazarken, özellikle de çok farklı dilleri ve sorun alanlarını kapsayan bir kodsa, kod sıkıştırma için toleransınız artar. Çocukların dev metinli kitaplarını okumaktan, daha küçük metinler ve daha büyük kelimelerle giderek daha karmaşık romanlara geçiş sürecinden farklı değildir.

...

Sıkıştırmaya karşı toleransı yüksek olan bir programcı aslında bir hikaye anlatımı ile engelleniyor. Niye ya? Çünkü bir kod tabanını anlamak için kafanıza mümkün olduğunca çok şey sığdırmanız gerekir. Bu karmaşık bir algoritma ise, deneyimli bir programcı her şeyi ekranda görmek istiyor, bu da boş satırların ve satır içi yorumların sayısını azaltmak anlamına geliyor - özellikle de kodun ne yaptığını yineleyen yorumlar. Bu bir n00b programcısının istediği şeyin tam tersi. n00b'ler her seferinde bir ifadeye veya ifadeye odaklanmak, etrafındaki tüm kodu, görüşün dışında tutmak, böylece yüksek sesle ağlamak için odaklanmak istiyor.

Ben temelde ona katılıyorum. Kodu sıkıştırmak çok daha iyidir, böylece bir ekranda çok fazla boşluk bırakmak yerine mümkün olduğunca fazlasını elde edebilirsiniz. Asla boş satır kullanmamalısın demek değil . Sadece, yaratmaya çalıştığınız gruplamanın okunabilirliği çok arttırmadığı, iyiden daha fazla zarar vermediği kanısındayım.

Bir Profesör Emeritus, İki Harika Tavsiye Verdi

1. Boşluk Ücretsiz
2. Kağıdın önünden geri dönen zımbaları kullanmayın, yoksa başarısız olurum.

Temel kurallarım şunlardır:

1. Dün yazdığım kodu okumakta zorlanıyorsam, muhtemelen bir veya üç yöntem çıkarmam gerekiyor.

2. Sınıf tanımımın kolay okunamayacak kadar uzun olması durumunda, muhtemelen bir modül / arayüz / nesneyi çıkarmam gerekiyor.

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

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

Beyaz alanları paragrafla aynı şekilde düşünmeyi seviyorum. Tek bir fikre katkıda bulunan satırları birlikte gruplandırıyorsunuz.

Yeni bir fikir veya aynı fikrin yeni bir yönünü başlatıyorsanız, yeni bir paragrafa başlarsınız - bunun gibi.

Emir kodunda, tek bir tutarlı görevi yerine getiren görevleri birlikte gruplarım; bildirim kodunda, bir fikrin tutarlı bir ifadesini tanımlayan kodu birlikte gruplarım.

Bunu İngilizce'de yapmakta zorluk çekmiyorsunuz (bazı insanlar paragraflama konusunda korkunçlar), bu nedenle küçük bir uygulamada, aynı beceriyi kodlamaya uygulamak hiç zor olmamalıdır.

Boş çizgiler bence şarttır. Onları farklı mantıksal kod bloklarını ayırmak için kullanıyorum. Kodu okunabilir hale getirir. Okunabilir kod iyi kod;)

İdeal kod parçam, her mantıksal bloğun boş bir çizgi ile ayrılması ve her bir bloğun üzerinde ana mantığı olan bir yorum olması olabilir.

Elbette, insanlar her yere birden çok boş satır ekleyerek yaparlarsa, çok rahatsız edici buluyorum :(

Bildirimleri ve kodu ayırmak için yalnızca bir işlev / yöntem içindeki boşlukları kullanıyorum.

Bazı mantıkları uygulayan kod alt bloklarını ayırmak için bazı satırların olması gerektiğini düşünüyorsanız, bunlar ancak başka bir fonksiyon / özel yöntemde olmalıdır. Bunu bir yükü fazla büyütmemek derleyicinize kalmış.

genellikle, peusdo kodunda:

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

    CODE
    BLOCK_START
        INITIALIZERS

        CODE
    BLOCK_END
    CODE
end

Yararsız boşluklar görürsem, genellikle tokatlarım.

Beyaz boşluk son derece değerlidir.

İşte anlaşma ... E = MC ² gibi karmaşık kod yazan inekler hırsız programlama becerilerini gösteren harika bir yöntemdir.

Şimdi altı ay ileri atlayalım ve sabah saat 2: 00’dir ve altı aydır bakılmayan sistem E = MC ² satırında bozulmuştur. . Bu hata ayıklamak neredeyse imkansız ... herkes çıldırıyor.

Diyelim ki kod böyle görünüyordu ...

See Dick
See Jane
See Dick and Jan

Saat 2:00 am ve kod bozuksa. Hızlı bir bakış size satır üç olması gerektiğini gösterecektir

See Dick and Jane

Sorun çözüldü.

Bottom Line ... boşluk kullanın.

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

Kabul ediyorum, boşlukları da aynı şekilde kullanıyorum. Ancak, bir yöntemi çok fazla parçaya bölmek için kendimi boşluk kullanarak bulursam, bu kodu birden çok yönteme yeniden yerleştirmem gerekebilir. Bir yöntemde çok fazla mantıksal bölüm, yöntemin test edilmesinin zor olacağını işaret edebilir.

Onları kodları mantıksal birimlere ayırmak için kullanıyorum. Boş satır kullanmayan çok az sayıda kod örneği gördüm, şaşkınlık dışında.

Psikopat cevabı en iyisidir, ancak bir sonraki kişinin bir aptal olduğunu ve onların olduğunu varsaydıklarını ve yanlış olduğunu ispatlamak isteyeceğini varsaymak yerine, bunun yerine geçeceğim.

Okunabilirlik için aynı derecede önemli yorumların kullanılmasıdır. Her işlevi veya alt yordamı bir yorum bloğu ile açıyorum, açık bir şekilde, ne olduğunu, ne yaptığını, argümanların ne olduğunu ve beklenen sonuçların ne olduğunu (hata durumlarının bir listesini de içeren) açıklıyor. Öyleyse, neyin amaçlandığı ve / veya ne yapılması gerektiği ile ilgili bir soru yoktur. Elde ettiği şey değişebilir, ama bu yolun ilerisinde.

Bence çok fazla kodlayıcı ya kendilerinin olacağını, ya da kod üzerinde "onarım" yapacaklarını ya da umursamadıklarını varsayıyorlar.

Boş satırlar önemlidir. Bununla birlikte, açılış parantezindeki boş bir çizgiyi boşa harcamak, ekran görüntüsünde görebileceğiniz kod miktarını azaltır. Olmalı:

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

   array[i] += 2;
}

(Beni '' 'ayracı ile' 'örgü' 'satırının aynı satırda tutmaya başlamasına izin verme).

Evet. Okunabilirliği için. Bazen yazmadığım kodlara boş satırlar bile koyarım. Boş satırlar üzerinden mantıksal gruplandırma yaptıklarında kodun anlaşılmasını daha kolay buluyorum;

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

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

İnsanlar üzerinde bakım yapmak zorunda kalırlarsa size temiz bir kod vereceklerdir;)

Microsoft StyleCop tarafından önerilen boşlukları kullanıyoruz. Okunabilirlik ve tutarlılığın yanı sıra (küçük sınıf boyutlarıyla birlikte) doğru şekilde kod koyduğumu, bir ekipteki çeşitli kişilerin aynı alanlarda çalışmakta olduklarında birleşmeleri yönetmeyi çok daha kolaylaştırdığını gördüm.

Sadece hayal gücümün olup olmadığından emin değilim, ancak farklı araçlar düzgün bir şekilde yerleştirildiğinde birleşme sırasında eşdeğer kodun nerede başladığını ve bittiğini anlamak için daha iyi bir iş yapıyor gibi görünüyor. Güzel düzenlenmiş kod birleştirmek için bir zevktir. Tamam, bu bir yalandı - ama en azından acı idare edilebilir seviyelerde tutuldu.

Asla boş bir satır değil, tüm dosyada değil. Bu, kodda bir boşluk olmadığını söylemek değildir:

 code;
 //
 morecode;

Boş satırlar üzerinde çalışılacak kod bölümlerini açmak içindir, editörünüzde sizi önceki / sonraki boş satıra götürmek için bir kaç kısayol tuşu vardır.