it-swarm.asia

Tanımlayıcılardaki boşluklara izin vermek bir programlama dili için kötü bir tasarım mı?

Bazı ( link 1 , link 2 ) programlama dilleri tanımlayıcılarında boşluklara izin verir (örneğin, değişkenler, prosedürler), ancak bunların çoğu programcılar genellikle kullanmaz ve deve vakası , yılan davası ve isimleri kelimeleri ayırmanın diğer yolları.

Boşlukları ve hatta diğer Unicode karakterleri desteklemek için bazı programlama dilleri, başlangıcını ve sonunu sınırlamak için adın belirli bir karakterle kapsüllenmesine izin verir.

Mekanlara izin vermek kötü bir fikir mi, yoksa tarihsel nedenlerden ötürü yaygın olarak izin verilmiyor mu?

Soru daha çok yeni oluşturulan programlama dillerinde uygulamanın ana artıları ve eksileri ile ilgilidir.

İlgili sayfalar: bağlantı 1 , bağlantı 2 .

51
user7393973

Aşağıdakileri göz önünde bulundur.

 var [Example Number] = 5;
 [Example Number] = [Example Number] + 5;
 print([Example Number]);

 int[] [Examples Array] = new int[25];
 [Examples Array][[Example Number]] = [Example Number]

Daha geleneksel örnekle karşılaştırın:

 var ExampleNumber = 5;
 ExampleNumber = ExampleNumber + 5;
 print(ExampleNumber);

 int[] ExamplesArray = new int[25];
 ExamplesArray[ExampleNumber] = ExampleNumber;

Eminim ki beyninizin ikinci örneği okuma zorluğunun çok daha düşük olduğunu fark ettiniz.

Bir tanımlayıcıdaki boşluklara izin verirseniz, bir Word'ün başlangıcını ve bitişini işaretlemek için başka bir dil öğesi koymanız gerekir. Bu sınırlayıcılar beyni ekstra ayrıştırma yapmaya zorlar ve hangisini seçtiğinize bağlı olarak insan beyni için yepyeni bir belirsizlik sorunları kümesi oluşturur.

Sınırlayıcılar koymazsanız ve kodu yalnızca içeriğe göre yazarken hangi tanımlayıcıdan bahsettiğinizi çıkarmaya çalışırsanız, başka bir tür solucan kutusu davet edersiniz:

 var Example = 5;
 var Number = 10;
 var Example Number = Example + Number;

 int[] Examples Array = new int[25];
 Examples Array[Example Number] = Example Number;

 Example Number = Example Number + Example + Number;
 print text(Example Number);

Mükemmel yapılabilir.

Beyninizin desen eşleşmesi için tam bir acı.

Bu örnekler sadece seçtiğim kelimelerin seçimi nedeniyle değil, aynı zamanda beyniniz her tanımlayıcının ne olduğunu tanımlamak için biraz zaman harcıyor.

Daha düzenli formatı bir kez daha düşünün:

 var Example = 5;
 var Number = 10;
 var ExampleNumber = Example + Number;

 int[] ExamplesArray = new int[25];
 ExamplesArray[ExampleNumber] = ExampleNumber;

 ExampleNumber = ExampleNumber + Example + Number;
 printText(ExampleNumber);

Bir şey fark ettin mi?

Değişkenlerin isimleri hala korkunç, ama onu okumak için zorlanma aşağı indi. Bunun nedeni beyninizin artık her Sözün başlangıcını ve sonunu tanımlamak için doğal bir çapaya sahip olması ve düşünmenizin o kısmını soyutlamanıza olanak vermesidir. Artık bu bağlam için endişelenmenize gerek yok - metinde bir mola görüyorsunuz, bunun yeni bir tanımlayıcı geldiğini biliyorsunuz.

Kodu okurken, beyniniz şu anda aklınızdakilerle çok fazla read kelimeleri eşleşiyor değildir. Gerçekten "SampleWord" okumak için durmak yok. Nesnenin genel şeklini görüyorsunuz, ExxxxxxWxxd, zihinsel yığınızda sakladığınız şeyle eşleşiyor ve okumaya devam ediyorlar. Bu nedenle "ÖrnekWord = ExapmleWord" gibi hataları kaçırmak kolaydır - beyniniz gerçekten okumuyor. Sadece benzer şeyleri eşleştiriyorsunuz.

Bir kez daha aşağıdakileri göz önünde bulundurun:

 Example Word += Example  Word + 1;

Şimdi bu kodu hata ayıklamaya çalıştığınızı hayal edin. "Örnek Kelime" de bu ekstra alanı kaç kez özleyeceğinizi düşünün. Yanlış yerleştirilmiş bir harf, ilk bakışta tespit etmek için çatal gibi zaten zordur; fazladan bir boşluk daha büyük bir mertebedir.

Sonunda, boşluklara izin vermenin metni more okunabilir hale getireceğini söylemek zor. Ek terminatörlerin ek güçlüklerinin ve beynimdeki ekstra yükün, birlikte çalıştığım dilde sahip olsaydı, bu tür işlevselliği kullanmaya değeceğine inanmakta zorlanıyorum.

Şahsen, kötü tasarım olarak görüyorum - derleyici, yorumlayıcı veya herhangi bir şeyle uğraşmaktan dolayı değil, çünkü beynim bunun yeni bir tanımlayıcı olduğunu düşünerek bu boşluklara gidiyor değil, başlar.

Bir bakıma, dal tahmini söz konusu olduğunda, beynimiz işlemcilerimizle aynı sorunları yaşar.

Lütfen, düşünce trenlerimize karşı nazik olun. Tanımlayıcılarınızın üzerine boşluk bırakmayın.

101
T. Sar

Tanımlayıcılardaki boşluklara izin vermek bir programlama dili için kötü bir tasarım mı?

Kısa cevap:

Olabilir.

Biraz daha uzun cevap:

Tasarım, karmaşık sorunlara yönelik çelişkili çözümleri belirleme ve ağırlıklandırma ve paydaşların ihtiyaçlarını karşılayan iyi tavizler verme sürecidir. bu paydaşların hedefleri bağlamında dışında “kötü tasarım” veya “iyi tasarım” yoktur ve bu hedeflerin ne olduğunu söylemediniz, bu yüzden soru cevaplamak için çok belirsizdir.

Daha da uzun cevap:

Yukarıda bahsettiğim gibi, dil tasarımcısının ele aldığı seçim bölgesi hedeflerine bağlıdır. Bildiğim iki dili düşünelim: MSIL'in insan tarafından okunabilir formu, C # 'ın derlediği düşük seviye "ara dil" ve C #.

C #, Microsoft'un stratejik olarak önemli olduğunu düşündüğü ortamlarda iş kolu geliştiricilerini son derece üretken kılan bir dil olarak tasarlanmıştır. C # 'da, bir tanımlayıcı, tüm karakterlerin alfasayısal veya _ Olarak sınıflandırıldığı ve ilk karakterin bir sayı olmadığı bir veya daha fazla UTF-16 karakterinden oluşan bir dizidir.

Bu sözcüksel dilbilgisi, stratejik olarak önemli LOB geliştiricilerinin ihtiyaçlarına uygun özelliklere sahip olacak şekilde dikkatle seçildi:

  • Bir tanımlayıcı olarak açık bir şekilde lexable; Örneğin, 1e10 Yasal bir tanımlayıcı olmamalıdır, çünkü çift olarak sözlü olarak belirsizdir.
  • Özel bir alanı adlandırmak gibi C, C++ ve Java'da yaygın olarak kullanılan deyimleri destekler _foo. C #, zaten ortak bir LOB dili bilen geliştiricilere hitap etmek için tasarlanmıştır.
  • Hemen hemen her insan dilinde yazılmış tanımlayıcıları destekler. C # 'da var φωτογραφία = @"C:\Photos"; Yazmak istiyorsunuz, hemen ileri gidiyorsunuz. Bu, dili anadili İngilizce olmayan geliştiriciler için daha erişilebilir hale getirir.

Ancak, C # tanımlayıcılardaki boşlukları desteklemez.

  • Sözcüksel dilbilgisini karmaşıklaştıracak ve daha sonra çözülmesi gereken belirsizlikleri ortaya çıkaracaktır.
  • Birlikte çalışma durumlarının büyük çoğunluğunda, gerekli değildir. Hiç kimse kamu mensuplarının içinde boşluklar olmasını isimlendirmez.

C # tanımlayıcılarında harf ve rakam dışındaki karakterlere izin vermemek iyi bir fikirdi.

Buna karşılık MSIL'de, bir yöntemi yöntem adlarına boşluk veya diğer "garip" karakterler koymak da dahil olmak üzere hemen hemen her şeyi adlandırabilirsiniz. Ve aslında C # derleyicisi bundan faydalanır! Doğrudan kullanıcı kodu ile çağrılmaması gereken derleyici tarafından üretilen yöntemler için "konuşulamaz adlar" oluşturur.

Neden bu MSIL için değil C # için iyi bir fikir? MSIL kullanım örnekleri tamamen farklı olduğundan:

  • MSIL birincil geliştirme dili olarak tasarlanmamıştır; bu bir ara dildir, bu nedenle birincil kullanım durumu derleyicilerinin çıktılarını anlamaya çalışan derleyici geliştiricileri içindir.
  • MSIL, tanımlayıcılarda boşluklara izin veren pre..NET Visual Basic ve diğer OLE Otomasyon istemcileri de dahil olmak üzere any eski Microsoft geliştirme ortamı ile birlikte çalışabilecek şekilde tasarlanmıştır.
  • Yukarıda belirtildiği gibi, bir işlev için "açıklanamayan" bir ad üretebilmek hata değil bir özelliktir.

Tanımlayıcılarda boşluklara izin vermek iyi bir fikir mi? Dilin kullanım durumlarına bağlıdır. İzin vermek için sağlam bir kullanım durumunuz varsa, kesinlikle izin verin. Eğer yapmazsan, yapma.

Daha fazla okuma: Karmaşık tanımlayıcıları mükemmel şekilde kullanan büyüleyici bir dil örneği istiyorsanız, metin tabanlı macera oyunları için bir DSL olan Inform7 konusuna bakın:

The Open Plain is a room. 
"A wide-open grassy expanse, from which you could really go any way at all."

Bu, The Open Plain Adlı room türünde yeni bir nesne bildirir ve bu nesne daha sonra program boyunca bu şekilde adlandırılabilir. Inform7 tahmin edebileceğiniz gibi çok zengin ve karmaşık bir ayrıştırıcıya sahiptir.

İşte daha karmaşık bir örnek:

Before going a direction (called way) when a room (called next location) is not visited:
  let further place be the room the way from the location;
  if further place is a room, continue the action;
  change the way exit of the location to the next location;
  let reverse be the opposite of the way;
  change the reverse exit of the next location to the location.

way ve next location Ve further place Ve reverse öğelerinin bu dilde tanımlayıcılar olduğunu unutmayın. Ayrıca next location Ve the next location Öğelerinin takma adlara sahip olduğuna dikkat edin. (Alıştırma: Bu kod, oyundaki odaların haritasını tutan veri yapısına ne yapıyor?)

Inform7, kaynak kod olarak doğal görünen İngilizce dilini tam olarak isteyen bir seçmene sahiptir. Bu Inform7'yi şu şekilde yazmak garip görünüyor:

  change the way exit of the location to the_next_location;

Bunu yapmak daldırıcıdır. Bunu T. Sar'ın zıt noktayı oluşturan (mükemmel) cevabı ile karşılaştırın - LOB dillerindeki geliştiricilerin, tanımlayıcıların nerede olduğunu zihinsel olarak ayrıştırmaya çalışmasının daldırıcı olması. Yine, bağlam ve hedeflere iner.

59
Eric Lippert

Nispeten iyi bilinen bir örnek , tek bir yazım hatasının kodun anlamını tamamen değiştirdiği bazı Fortran kodlarıdır.

Kodun bir bölümünü 100 kez (döngü sayacı olarak I ile) tekrarlamak amaçlanmıştır:

DO 10 I = 1,100

Bununla birlikte, virgül bir nokta olarak yanlış yazılmıştır:

DO 10 I = 1.100

Fortran, tanımlayıcılarda boşluklara izin verdiği için (ve henüz bildirilmemişlerse otomatik olarak değişkenler oluşturduğundan), ikinci satır tamamen geçerlidir: dolaylı olarak DO10I adlı sahte bir gerçek değişken oluşturur ve 1.1 sayısını atar. Böylece program hatasız derlenmiş; sadece döngü çalıştırılamadı.

Söz konusu kod bir roketi kontrol etti; Tahmin edebileceğiniz gibi, bu tür bir hata felaket olabilir! Neyse ki, bu durumda, hata test sırasında yakalandı ve hiçbir uzay aracı zarar görmedi.

Bence bu tanımlayıcılarda boşluk bırakmanın tehlikelerinden birini gösteriyor ...

15
gidds

Tanımlayıcılardaki boşluklara izin vermek bir programlama dili için kötü bir tasarım mı?

Önemli uygulama ayrıntılarını unuttunuz:

sizin için kaynak kod nedir?

FSF tanımını beğendim: geliştiricilerin üzerinde çalıştığı tercih edilen form. Sosyal bir tanımdır, teknik değil.

Bazı dillerde ve 1980'lerin uygulanmasında (orijinal Smalltalk ve 1980 Smalltalk makineleri düşünün), kaynak kodu bir dizi karakter değildi. Bu soyut sözdizimi ağacı idi ve kullanıcı tarafından fare ve klavye ile manipüle edildi.

Bir anlamda Common LISP sembollerindeki boşlukları kabul eder.

Hem programlama dilinizi (belgelenmiş hem de sözdizimi ve - veren bazı raporlarda birlikte tasarlamaya karar verebilirsiniz (bu lot ​​iş). anlambilim ), uygulaması (bazı yazılımlar gibi) ve editörü veya IDE (bazı yazılımlar gibi).

tunes.org ile ilgili eski tartışmaları okuyun. INRIA'daki eski eseri

@TechReport{Jacobs:1992:Centaur,
 author =       {Jacobs, Ian and Rideau-Gallot, Laurence},
 title =        {a {\textsc{Centaur}} Tutorial},
 institution =  {\textsc{Inria} Sophia-Antipolis},
 year =         1992,
 number =       {RT-140},
 month =        {july},
 url =          {ftp://www.inria.fr/pub/rapports/RT-140.ps}
}

ve

@techreport{donzeaugouge:inria-mentor,
 TITLE =        {{Programming environments based on structured
                 editors : the \textsc{Mentor} experience}},
 AUTHOR =       {Donzeau-Gouge, Véronique and Huet, Gérard and Lang,
                 Bernard and Kahn, Gilles},
 URL =          {https://hal.inria.fr/inria-00076535},
 TYPE =         {Research Report},
 NUMBER =       {RR-0026},
 INSTITUTION =  {{INRIA}},
 YEAR =         1980,
 PDF =
              {https://hal.inria.fr/inria-00076535/file/RR-0026.pdf},
 HAL_ID =       {inria-00076535},
 HAL_VERSION =  {v1},
}

Ayrıca bakınız Bismon taslak raporum ve http://refpersys.org/

RefPerSys hayalim böyle bir deklaratif programlama dilini Nice IDE bunun için tasarlıyor. On yıl alabileceğini biliyorum. Bir anlamda deli olduğumuzu düşünmekten çekinmeyin. Biz!

Kullanılabilirlik açısından, sözdizimi renklendirme ve otomatik tamamlama , tanımlayıcılardaki boşluklardan daha önemlidir (ikisine de bakın GtkSourceView ve CodeMirror ilham için). Görsel olarak alt çizgi _ bir boşluk karakterine yakın görünüyor. Kendi IDE'nizi kodlarsanız, ctrlspace "adların içindeki boşluklar" için girdi olarak. Bence is ve ∀ "anahtar kelimeler" olmalı, soru onları nasıl yazacağınız oluyor. Yazmayı hayal ediyorum (LaTeX'ten esinlenerek) \forallESC ∀ (ve bunun için bazı emacs alt modunu duydum).

Not: Beyaz boşluklardan (veya sekmelerden) önemli olduğu için Python (ve Makefile - s) nefret ediyorum.

8

Sembol isimlerinde izin ver boşluklar için doğal olarak kötü bir tasarım değildir. Bu basit bir karşı örnekle gösterilebilir.

Kotlin isimlerde boşluklara izin verir. Ayrıca resmi kodlama kuralları vardır bu özelliği kullanmak için uygun olduğunda :

Test yöntemlerinin adları

Testlerde (ve sadece testlerde), boşluklara kapalı boşluklarla yöntem adlarının kullanılması kabul edilebilir.

Misal:

class MyTestCase {
     @Test fun `ensure everything works`() { /*...*/ }

"İyi" ve "kötü" elbette özneldir, ancak test yöntemi adlarında boşluklar kullanmak, test kodunu okumak için çok daha hoş hale getirir ve sonuçları test eder. okunabilir bir test açıklaması ayrı olarak.

Buradaki önemli nokta, bu yöntemlerin normalde insanlar tarafından yazılan koddan açıkça çağrılmayacağıdır, bu yüzden sadece adın göründüğü yer yöntem tanımındadır. Bence bu, sembol isimlerinde boşlukların ne zaman iyi bir fikir olabileceğini düşünmek için önemli bir ayrımdır: sadece sembol programcı tarafından sadece bir kez yazıldığında.

6
hyde

Temel kural:

Hatalar, kodu yüksek sesle okumak için geçen süre ile orantılıdır.

Açık köşeli ayraç, kapalı köşeli ayraç, açık küme ayracı, açık küme ayracı, açık parantez, yakın parantez sayısını artıran her şey koddaki hata sayısını artıracaktır.

Bu, yıldız işaretinin değil, yıldızın veya uyarının olmasının nedenlerinden biridir. # şşşt,! patlama. Şüphelendiğim matematikçilerin sembolleri için de kısa sözlü ifadeleri var, eminim.

Bu yüzden teknoloji alanları kısaltmalar ve kısaltmalar ile doluyor: Kelimelerle düşünüyoruz. Sonlu bir dikkat süremiz var ve kafamızda sadece çok fazla sembol tutabiliriz. Böylece şeyleri bir araya getirip topluyoruz.

ReallyReallyLongIdentifier aynı şeyi yapabilir. Orada ödünleşmenin ne için olduğunu hatırlamak ve düşünce süreçlerimize karışmak arasında. Ama ReallyReallyLongIndentifer hala QzslkjfZslk19 daha iyidir

Yaratılışından ne kadar uzakta kullanılırsa, o kadar unutulmaz olması gerekir. Böylece, i, j, k ilmek yapıları için kullanılır - bir ilmek ömrü boyunca yaşadıkları mayflies gibi ve bu ilmek aynı ekranda başlar ve biter.

Bu kodlamaya da uzanır:

A = FunctionAlpha (21, $ C $ Q)

B = FunctionBeta ($ A, $ D $ R)

daha temiz

B = FunctionBeta (FunctionAlpha (21, $ C $ Q), $ D $ R)

Ben bu yayılma sayfaları böyle kötü bir hata oranları kötü kodlama neden bir nedeni olduğunu düşünüyorum: Geçici hücre/satır/sütun ekleyerek dışında dağınık iç içe ifadeleri önlemek için hiçbir yolu yoktur.

3

Hiçbir zaman en iyi dilin olmayacağına gerçekten bakmam çok uzun sürdü. Bir programlama ekibi için en önemli hususlar, dilin iyi bilinmesi, birçok araç tarafından desteklenmesi, minimum dil sözdizimine sahip olması ve sizi mümkün olduğunca nadiren şaşırtmasıdır.

Tek bir kodlayıcı için hızlı test/çalıştırma döngülerine izin veren güçlü bir dil mükemmeldir.

Bir yönetici için, işletim sisteminin Kabuk diline göre uyarlanmış bir dil önemlidir.

Disiplinler arasında paylaşılan bazı çalışma dilleri için DSL'ler Güzel olabilir.

Muhtemelen boşluklu bir dil için bir yer var mı? Şaşırtıcı olmayan kuralları ihlal ediyor, ancak DSL hedeflerine çok iyi uyuyor.

Kimsenin bahsetmediğini sanmıyorum bir şey - bir özel IDE ile aslında zor bir alan ve yumuşak bir alan olabilir. Onlar benzer olurdu (belki IDE farklı tonları var) .

Bu nedenle, şu anda herhangi bir dille yapabilirsiniz - sadece alt satırların boşluk olarak görüntülenmesi için IDE) bir geçiş yapın. Eclipse eklentileri yapan herkes bunu muhtemelen bir saat içinde yapabilir .

Deve davasını pragmatik olarak "boşluklu kelimelere" dönüştürmek de mümkündür, IDE bunu sizin için yapabilirdi ama biraz tuhaf olurdu.

0
Bill K