Kıvırcık ayraç çorbası ile başa çıkmak

Yıllarca hem C # hem de VB.NET'te programladım, ancak öncelikle VB'de. C # 'a doğru bir kariyer değişikliği yapıyorum ve genel olarak C #' ı daha iyi seviyorum.

Yine de yaşadığım bir konu kıvırcık süslü çorba. VB'de, her bir yapı anahtar kelimesinin eşleşen bir yakın anahtar kelimesi vardır, örneğin:

Namespace ...
    Class ...
        Function ...
            For ...
                Using ...
                    If ...
                        ...
                    End If
                    If ...
                        ...
                    End If
                End Using
            Next
        End Function
    End Class
End Namespace

C # 'da yazılan kodun okunması çok zor:

namespace ... {
    class ... {
        function ... {
            for ... {
                using ... {
                    if ... {
                        ...
                    }
                    if ... {
                        ...
                    }
                }
            }
            // wait... what level is this?
        }
    }
}

VB için çok alışkın olmak, c-tarzı programcılar tarafından okunabilirliği artırmak ve kodunuzun doğru "blokta" bitmesini sağlamak için kullanılan bir teknik olup olmadığını merak ediyorum. Yukarıdaki örneği okumak nispeten kolaydır, ancak bazen bir kod parçasının sonunda, ilgilendiğim bloğu bitirdiğini anlamak için birkaç sayfayı yukarı kaydırmamı gerektiren 8 veya daha fazla kıvırcık parantezim olacak. içinde.

Kıvırcık parantezinizi bitişinizle aynı "rütbe" ye koyun, şöyle:

namespace ... 
{
    class ... 
    {
        function ... 
        {
            for ... 
            {
                using ... 
                {
                    if ... 
                    {
                        ...
                    }
                    if ... 
                    {
                        ...
                    }
                }
            }
            // It's the `function` level!
        }
    }
}

• IDE'nize bağlı olarak: imlecinizi açma / kapama ayracı üzerine getirdiğinizde, hem bunu hem de karşılık gelen ayracı vurgulayacaktır.
• Bloğu daraltın ve nerede açıldığını / kapandığını gösterir.
• Daha küçük kod blokları yazın. Ciddi anlamda. Kontrol edin Clean Codeve bu sorunla bir daha asla karşılaşmayın (ve daha okunabilir / bakımı kolay kodlara sahip olun).

Bir not, aşağıdaki özel durumunuza yardımcı olabilecek geçerli c # sözdizimidir:

using (var type = new MyDisposable1())
using (var type2 = new MyDisposable2())
{
    /* do what you will with type2 and type2 */
}

Yaygın bir kural, kapandığı yapıyı belirtmek için kapanış ayracı sonrasında bir yorum eklemektir:

if {
   ...
} // end if

while (condition) {
   ...
} // end while

Bu konvansiyona hiç ısınmadım, ama bazı insanlar bunu yararlı buluyor.

Genel olarak, herhangi bir tarzda kaşlı ayraçları eşleştirmek zorlaştığında - muhtemelen yöntemin çok uzun olduğu ve yeniden faktörlendirilmesi gerektiği anlamına gelir.

Bence parantez ile zorlamanız gerekiyor. Sonunda size ikinci bir doğa olacaklar ve onlar olmadan nasıl yaşadığınızı merak edeceksiniz.

Yine de uygun şekilde girintili olduklarından ve bazı boşluk kurallarına uyulduğundan emin olun (hangisinin önemli olmadığı).

Ad alanını ve sınıf kapsamlarını yatay olarak daraltarak 2 düzey iç içe yerleştirme düzeyini kaldırırım. Yöntemlerin ekranın sol kenarıyla aynı hizada olduğuna dikkat edin. Her dosyada 2 girinti seviyesini kaybetmenin anlamını görmüyorum.

Bundan sonra 4 seviyeden daha derin iç içe olacaksınız.

namespace FooNameSpace {
class Foo {

public void bar()
{
    while(true)
    {
        while(true)
        {
            break;
        }
    }
}

public void fooBar()
{
    foreach(var item in FooList)
    {
        foreach(var b in item.Bars)
        {
            if(b.IsReady)
            {
                bar();
            }
            bar();
        }
        bar();
    }
}

}}//end class, namespace

Son zamanlarda, akış kontrolü yapıları hakkında temelde şu şekilde giden iki kuralı resmileştirmeye karar verdim:

• Gerekli kod akışı yapılarından başka bir şeye sahip olmamalısınız
• Kod akışı yapılarını mümkün olduğunca küçük yapmalısınız

Tam olarak bahsettiğiniz ve açıkça farkında olduğunuz nedenlerden dolayı, bunların takip edilmesi gereken harika kurallar olduğunu düşünüyorum. Bunları gerçekleştirmek için kullanabileceğiniz birkaç basit teknik vardır:

• En kısa sürede kapsamdan çıkın (bu, işlevlerin yanı sıra döngülerin kapsamını da içerir)
• Bahsettiğim gibi kapsamdan çıkma tekniğinden önceki işlevden çıkılarak hafifletilebilecek başkaları izleyin ve uygulayın
• Bir if içindeki kod dışarıdakinden daha büyük olduğunda koşullu denetimlerinizi tersine çevirin
• Döngünün boyutu, yöntemin geri kalanını gizlemek için büyüdüğünde, başka bir yönteme giden bir döngü içindeki faktör kodu
• Yalnızca başka bir kapsam içeren kapsamlara dikkat edin; örneğin, kapsamı if ile hiçbir şey olmadan bir if ile doldurulan bir işlev

Burada , bunlara uymamanın nasıl söylediğiniz gibi sonuçlanabileceği ve yanlış kod bloğuna kod koyabileceğinizle ilgili örnekler verdim , bu da kötü ve bakım sırasında ortaya çıkan hataların kolay bir nedeni.

Maalesef bu, bilgi işlemdeki en eski savaş nedenlerinden biridir. Makul argümanlar her iki taraftan da yapılabilir (daha iyi dikey gayrimenkul ekonomisi ve açılış ayracı kapanış ayracı ile görsel olarak daha kolay eşleştirme yeteneği), ancak gerçekte basit bir kaynak kodu formatlayıcı sizin için her şeyi çözecektir. MS Visual C #, iyi çalışan bir tane var.

Bununla birlikte, bir takımın parçası olarak çalışıyorsanız, o takımın kullandığı sözleşmelere uymanız beklenir, bu nedenle her iki stile de aşina olmak ve brace stilleri üzerinde dini olmaktan kaçınmak için ödeme yaparsınız.

Bu yüzden öğrenirken elbette öğrenmenizi kolaylaştıran stile odaklanın, ancak siz öndeyken diğer tarafa yarım göz atın ve iyi olacaksınız.

Yuvalamayı azaltmanın yollarını önermeye yardımcı olacak Yeniden Biçimlendir'i kullanın. Ayrıca, bir fonksiyonun sadece bir şey yapması gerektiğini vurgulayan Bob Martin'in Temiz Kodu adlı kitabını okuyun ve bu nedenle her fonksiyon sadece yarım düzine satır uzunluğunda olmalıdır, bu yüzden endişelenecek çok fazla yuvalama seviyesine sahip olmayacaksınız.

Düzenleyiciye size yardımcı olabilecek bir eklenti var: C # Anahat .

Eklenti, iç içe kod bloklarını daraltmak, genişletmek ve vurgulamak için özellikler ekleyerek VS # için VS20xx düzenleyicisini genişletir. Bu özellikler, if, while vb. Gibi kod bloklarının iç içe geçmiş içeriklerinin daha kolay düzenlenmesine ve okunmasına olanak tanır.

Kodunuzu Visual Studio'da yazarsanız, oluşturduğunuz her yapının başı ile sonu arasında dikey noktaları gösteren bir eklenti de vardır.

Ama genel olarak "Kıvırcık Parantez Çorbası" na alışmanız biraz zaman alacak. (Btw, bu ifadeyi gerçekten çok seviyorum. Kulağa Big Bang Theory için Bölüm Adı gibi geliyor)

Girinti her iki sözdizimi stilinde nerede olduğunuzu söyler. Bir VB programı veya bir C # programını tek bir satıra yazarsanız, iç içe geçmiş sözdiziminin neresinde olduğunuzu söyleyemezsiniz. Makine, blok bitiş ifadelerini veya kıvırcık parantezleri ayrıştırır, ancak insanların girintiye ihtiyacı vardır.

Blok bitiş ifadeleri, programlama çok daha az etkileşimli ve görsel olduğunda delikli kartlar ve kağıt bant çağından gelir. Ya da, gerçekten, hiç etkileşimli değil. Programlara girmek zordu ve bu yüzden programcıların sözdizimi analizi ve hata kurtarma konusunda çok akıllı olmaları için derleyicilere ihtiyaçları vardı.

Geçtiğimiz dönemde, düzenleme-derleme-çalıştırma döngüsü kart deliciyle delikli kartlar hazırlamayı ve sonra da bir katilin delikli kartları alıp makineye göndermesini sağlayan bir iş gönderme penceresine dizilmiş olabilir. Daha sonra programcı çıktıyı (kağıda basılmış) başka bir pencereden toplar. Programda hatalar olsaydı, çıktı yalnızca derleyici tanılamasından oluşur. Geri dönüş süreleri uzun olduğunda, tanılama kalitesini artırmaya yardımcı olursa end if, sadece yerine yazmanın ek maliyeti )haklıdır, çünkü programcı, zaman kaybını azaltmak için tek bir yinelemede mümkün olduğunca çok hatayı düzeltmelidir. iş gönderme penceresinden tekrarlar.

Kapanmış kıvırcık küme ayracı eksik olduğunda, hangi açık küme ayrağının kapalı olmayan küme ayracı olduğunu söylemek zor. (Derleyici, eğitimli bir tahmin yapmak için girintiyi ayrıştırmak zorunda kalabilir.) Bir işlevin içindeki kapanış ayracı silerseniz, dosyanın geri kalanının tamamı bu işlevin bir parçası gibi görünür, bu da yardımcı olmayan hata iletilerinin telaşlanmasına neden olur. Bir end functionsözdiziminiz varsa , derleyici hatalı işlevin nerede bittiği sonucunu çıkarabilir, sonraki işlevleri düzgün bir şekilde çözümleyebilir ve ayrıştırabilir ve varsa anlamlı olan ek tanılamalar sağlayabilir.

Kodunuzu otomatik olarak girintilendiren ve renklendiren koda duyarlı metin düzenleyicide çalışırken, altmış veya daha fazla satır görebileceğiniz yüksek çözünürlüklü bir ekranda, bu tür beceriksiz diller için argümanlar artık geçerli değildir. Programları o kadar hızlı bir şekilde düzenleyebilir ve yeniden oluşturabilirsiniz, böylece her seferinde tek bir hatayla başa çıkabilirsiniz. Ayrıca, programın büyük bölümlerini aynı anda ekranda görüp uygun girintiyi koruyarak, bu tür yuvalama hatalarının oluşumunu ilk etapta azaltabilirsiniz. Ve iyi programlama metin editörü yazarken bazı sözdizimi hatalarını bile işaretleyecektir. Dahası, bir programın bloklarını sözdizimine göre çökertecek ve yapısının "taslağa benzeyen" bir görünümünü veren katlama editörleri var.

Lisp parantezleri en başından beri kullandı ve belki de tesadüfen değil, Lisp korsanları programlamayı küçük parçalarda (ifadeler) kabul eden sistemler oluşturarak etkileşimli bir deneyim olarak öncülük etti.

Aslında, Python dilinin gösterdiği gibi, bitiş sembollerine hiç ihtiyacınız yoktur. İdentation sadece edebilirsiniz olmak yapısı. İnsanlar, makinenin bitiş sembollerine veya ifadelerine dayandığı dillerde bile kod yapısını incelemek için zaten girintiyi kullanıyorlar.

Bir IDE kullanıyorsanız, Crtl+ k+ düğmesine basmanız yeterlidir Dve IDE işin geri kalanını yapacaktır.