Bir dil neden bloklar için açık işaretleyicilere göre girintiyi tercih etmeli?

Haskell'i öğreniyorum ve otomatik girinti aracı arıyordum. Fazla bakmadım ve Haskell'de (Python'da olduğu gibi) girintinin bir bloğu ifade ettiğini öğrendim. Sonuç olarak, C ailesindeki diğer dillerde olduğu gibi, {} (kıvırcık ayraçlar) veya begin endanahtar kelimeler gibi açık işaretleyiciler kullanan bir otomatik biçimlendirme aracı oluşturmanın imkansız olduğunu tahmin ediyorum .

Okunabilirliği için bir girintiyi uygulayan bir dili umursamıyorum, ancak hem girintiyi zorlama hem de açık bir işaretleyiciye sahip olmanın faydalarını anlayamıyorum, böylece otomatik araçlar, hangi bloğa ait olduğunu anlayabilsin.

Bir blok işaretleme girinti tercihi, böylece kod daha iyi görünüyor , o zaman hala avantajı anlamıyorum. Sekmelerin ve boşlukların farklı editörlerde ve farklı yazı tiplerinde (örneğin daha düzenli görünüme sahip tek renkli fontlar) farklı şekilde temsil edildiği göz önüne alındığında, programcının kodu düzgün bir şekilde sunmasını beklemek mümkün değildir. Geçerli metin düzenleyiciyi dikkate alabilecek bir araç, kodu doğru biçimlendirmek için çok daha uygun olacaktır.

Bir dil tasarımcısı neden açık blok işaretleyicilere göre girintiyi seçsin?

Guido Von Rossum

Gönderen Guido Van Rossum röportajda tam metin görülebilir, books.google.com ile (vurgu benim):

Gruplandırma için girinti seçimi Python'da yeni bir kavram değildi; Bunu ABC'den miras aldım , ama aynı zamanda eski bir dil olan occam'da da meydana geldi. ABC yazarlarının fikri oklüzyondan mı, bağımsız olarak mı icat ettiğini, yoksa ortak bir ata olup olmadığını bilmiyorum. Tabii ki, diğer alanlarda yaptığım gibi ABC'nin öncülüğünü takip etmemeyi seçebilirdim (örn. ABC, dil anahtar sözcükleri ve prosedür adları için büyük harf kullandı, kopyalamadığım bir fikir), ancak özelliği oldukça beğendim ABC'yi kullanırken biraz, çünkü o zamanlar C kullanıcıları arasında yaygın olan belirli bir anlamsız tartışmayı ortadan kaldırmış gibi görünüyordu , kıvırcık parantezlerin nereye yerleştirileceği hakkında .

Von Rossum, ABC'den büyük ölçüde ilham aldı ve hepsini kopyalamak zorunda olmasa da, girinti kullanımı dini savaşlardan kaçınmak için yararlı olabileceğinden korundu.

Ayrıca okunabilir kodun gruplamayı belirtmek için gönüllü olarak girintiyi kullandığının farkındaydım ve girintinin kıvırcık parantez kullanarak sözdizimsel gruplama ile aynı fikirde olmadığı koddaki ince hatalarla karşılaştım - programcı ve yorumcular girintinin gruplandırmayla eşleştiğini varsaydılar. ve bu nedenle hatayı fark etmedim. Yine, uzun bir hata ayıklama oturumu değerli bir ders verdi.

Rossum ayrıca gruplama ve girinti arasındaki tutarsızlık nedeniyle hatalara tanık oldu ve görünüşe göre bu sadece kodu yapılandırmak için girinti dayanarak programlama hataları ¹ daha güvenli olacaktır .

Donald E. Knuth ve Peter J. Landin

Referans verilen röportajda Guido, Don Knuth'un girinti kullanma fikrinden bahseder. Bu ayrıntılı olarak yeniden keşfedilen Knuth Girinti Alıntı tırnak, git Tablolar ile Programlama Yapısal . Knuth ayrıca Peter John Landin'in sonraki 700 programlama diline de atıfta bulunmaktadır (girinti ile ilgili Tartışma bölümüne bakın). Landin, başlangıç / bitiş blokları yerine girintili ilk dile benzeyen ISWIM'i tasarladı . Bu makaleler daha çok programların yapılandırılmasında girinti kullanılmasının uygulanabilirliği ile ilgilidir.

_{1. Bunun gerçekte , gerçekleşmesi gereken programlama hatalarını yakalamak ve düzeltmek için hem gruplama yapılarına hem de otomatik biçimlendirmeye sahip olmanın lehine bir argüman olduğunu düşünüyorum. Python'daki girintinizi batırırsanız, kodunuzu hata ayıklayan kişinin hangisinin doğru olduğunu tahmin etmesi gerekir:}

if (test(x)):
  foo(x)
  bar(x)

_{Shall bardaima çağrılabilir veya sadece test başarılı olur?}

_{Gruplama yapıları, kodunuzu otomatik olarak girintili hale getirdiğinizde bir hatayı tespit etmenize yardımcı olan bir fazlalık düzeyi ekler. C'de eşdeğer kod aşağıdaki gibi otomatik girintili olabilir:}

if (test(x))
  foo(x);
bar(x);

_{Ben yönelik Eğer baraynı seviyede olmasını foootomatik girintilenmiş kod yapısına dayalı ardından, etrafı parantez ekleyerek sabitlenebilir şeylerin yanlış olduğunu görelim foove bar.}

_{In Python: Mitler Girintileme hakkında , C bir sözde kötü bir örnek vardır:}

/*  Warning:  bogus C code!  */

if (some condition)
        if (another condition)
                do_something(fancy);
else
        this_sucks(badluck);

_{Yukarıdaki durumla aynıdır, Emacs'ta tüm bloğu / işlevi vurgularım, Sekme tuşuna basarım ve daha sonra tüm kodlar yeniden girilir. İnsan girintisi ve kod yapısı arasındaki tutarsızlık bana bir şeyin kapalı olduğunu söyler (bu ve önceki yorum!).}

_{Ayrıca, C'de girintinin kapalı olduğu ara kod sadece ana daldan geçmez, tüm stil kontrolleri GCC / Jenkins'in çığlık atmasına neden olur. Geçenlerde Python'da yukarıda anlatılanla benzer bir sorun yaşadım, bir girinti seviyesi tarafından yapılan bir açıklama ile. Bazen bir kapanış ayracı ötesine C kodu var, ama sonra Tab vurmak ve kod "yanlış" girintiler: bu hatayı görmek için bir şans daha.}

Bu oldukça özneldir ve birçoğunun alev savaşının sebebidir. Ancak:

Aynı bilgileri iki farklı şekilde ifade ettiğiniz için blokları ve girintileri sınırlayan sembollere sahip olmak , KURU ilkesini ihlal eder . Otomatik girinti araçlarının varlığı olan belirti otomatik gereksiz bilgiler olduğunu girinti gösterileri oluşturabilir Yani, ve girinti ve semboller şu anlama gelir: Bu KURU ihlali olabilir kodunu yanıltıcı yol senkronizasyonu bozuluyor.

Python Tasarım ve Tarih SSS'si bunu açıkça belirtiyor:

Python neden ifadelerin gruplandırılması için girintiyi kullanıyor?

Guido van Rossum, gruplama için girinti kullanmanın son derece zarif olduğuna ve ortalama Python programının netliğine çok katkıda bulunduğuna inanıyor. Çoğu insan bir süre sonra bu özelliği sevmeyi öğrenir.

Başlangıç ​​/ bitiş parantezleri olmadığından, ayrıştırıcı ve insan okuyucu tarafından algılanan gruplama arasında bir anlaşmazlık olamaz.

Python için otomatik girinti aracı oluşturamayacağınız doğrudur, ancak bu iyi bir şeydir: Bu, sözdiziminde uzlaştırmak için otomatik araçlara ihtiyacınız olan fazlalıkların olmadığı anlamına gelir.

Sekmeler ve boşluklar Python'da meşru bir sorundur ve sekmeleri ve boşlukları (girinti için) asla aynı kod tabanında karıştırmamanız önerilir.

Python, (şimdi kullanılmayan) önceki dilde ABC'den gelen önemli girintiyi miras aldı. ABC, tasarımı yönlendirmek için kullanılabilirlik testini kullanan çok az programlama dilinden biridir . Bu yüzden sözdizimi hakkındaki tartışmalar genellikle öznel görüşlere ve kişisel tercihlere inerken, önemli girinti seçimi aslında daha sağlam bir temele sahiptir.

Dil tasarımcıları sözdizimsel açıdan önemli boşlukları seçerler çünkü yarı-kolonların ve parantezlerin kodu okurken gürültü eklediğine ve üretkenliğe zarar verdiğine inanırlar (veya en azından potansiyel kullanıcılarının inandığını düşünürler). Diğer bir yaygın neden, kötü / tutarsız kodlama stilinin okunabilirliğe zarar vermesidir - ortak bir girinti şemasını zorlayarak, dilin daha iyi okunabilirliği vardır. Otomatik biçimlendirme IDE'lerinin daha yaygın olması, ancak yine de uygulanabilmesi nedeniyle bu sonraki neden daha az önemlidir.