Çeşitli dil uygulamalarına Unicode tanımlayıcı desteği eklemenin anlamı nedir?

Ben şahsen kafa karıştırıcı Unicode tanımlayıcıları dolu okuma kodu bulmak. Bence, kodun kolayca korunmasını da engelliyor. Çeşitli çevirmenlerin yazarlarının böyle bir desteği uygulaması için gereken tüm çabayı belirtmiyoruz. Ayrıca, çeşitli dil uygulamalarının (gerçekten önemli olduğu gibi) avantajlarının (dis) avantajları listesinde Unicode tanımlayıcı desteğinin eksikliğini (veya varlığını) sürekli olarak fark ediyorum. Anlamıyorum: neden bu kadar dikkat?

Unicode düşündüğünüzde, Internet'te gördüğünüz Rusça yazılmış bazı kaynak kodlarını düşünmenizi sağlayan (Rusça bilmiyorsanız) Çince veya Rusça karakterler düşünürsünüz.

Ancak unicode yanlış bir şekilde kullanılabilirse, kaynak kodunda tek başına kötü olduğu anlamına gelmez.

Unicode ile belirli bir alan için kod yazarken kodunuzu kısaltabilir ve daha okunabilir hale getirebilirsiniz . Onun yerine:

const numeric Pi = 3.1415926535897932384626433832795;
numeric firstAlpha = deltaY / deltaX + Pi;
numeric secondAlpha = this.Compute(firstAlpha);
Assert.Equals(math.Infinity, secondAlpha);

Yazabilirsin:

const numeric π = 3.1415926535897932384626433832795;
numeric α₁ = Δy / Δx + π;
numeric α₂ = this.Compute(α₁);
Assert.Equals(math.∞, α₂);

Bu, ortalama bir geliştirici için okunması kolay olmayabilir, ancak günlük olarak matematiksel sembolleri kullanan bir kişi için okunması hala kolaydır .

Veya, SLR fotoğrafçılığı ile ilgili bir uygulama yaparken:

int aperture = currentLens.GetMaximumAperture();
Assert.AreEqual(this.Aperture1_8, aperture);

Eğer yerine diyaframı daha yakın bir yazı ile, 's sembol ƒ tarafından ƒ/1.8:

int ƒ = currentLens.GetMaximumƒ();
Assert.AreEqual(this.ƒ1¸8, ƒ);

Bu rahatsız edici olabilir : genel C # kodunu yazarken, yazmayı tercih ederim:

var productPrices = this.Products.Select(c => c.Price);
double average = productPrices.Average()
double sum = this.ProductPrices.Sum();

ziyade:

var productPrices = this.Products.Select(c => c.Price);
double average = productPrices.x̅()
double sum = productPrices.Σ();

çünkü ilk durumda, IntelliSense neredeyse tüm kodu yazmadan ve özellikle faremi kullanmadan yazmama yardımcı olurken, ikinci durumda, bu sembolleri nerede bulacağım hakkında hiçbir fikrim yok ve gitmek için fareye güvenmek zorunda kalacağım ve otomatik tamamlama listesinde arayın.

Bununla birlikte, bazı durumlarda hala yararlıdır. currentLens.GetMaximumƒ();önceki örneğimin IntelliSense'e güvenebilir GetMaximumApertureve daha kısa ve daha okunabilir olması kadar kolay yazılabilir . Ayrıca, çok sayıda simgeye sahip belirli etki alanları için, klavye kısayolları , sembolleri kaynak koddaki değişmez eşdeğerlerinden daha hızlı yazmaya yardımcı olabilir .

Aynı şey, bu arada, yorumlar için de geçerlidir. Kimse Çince yorumlarla dolu kodu okumak istemez (Çince'yi iyi bilmiyorsanız). Ancak bazı programlama dillerinde unicode sembolleri hala yararlı olabilir. Bir örnek dipnotlardır¹.

^{Comments Kesinlikle C # kodunda yorum yazmanın stil kurallarının katı bir setinin olduğu dipnotların tadını çıkarmayacağım. Öte yandan PHP'de açıklanacak çok şey varsa, ancak bunlar çok önemli değilse, neden bunları dosyanın altına koymuyorsunuz ve yöntemin PHPDoc'unda bir dipnot oluşturmuyorsunuz ?}

Şöyle söylerdim:

1. programlamayı öğrenen (örneğin okulda) ve İngilizce bilmeyen profesyonel olmayan ve acemileri kolaylaştırmak. Zaten üretim kodu yazmıyorlar. Kod gibi birçok kez gördüm:

   double upsos, baros;
   cin >> upsos >> baros;
   

   Sadece zavallı adamın kendi dilinde yazmasına izin verin:

   double ύψος, βάρος;
   cin >> ύψος >> βάρος;
   

2. Sevmedin mi?

   class ☎ {
   public:
       ☎(const char*);
       void 📞();
       void 🎧(👨);
   };
   
   ☎ ☏("031415926");
   ☏.🎧(👨("Bob"));
   ofstream f;
   f.💾();
   

Tabii ki, her modern derleyici bugün Unicode kaynak koduyla uğraşmalıdır. Örneğin, dize sabitlerinin Unicode karakterleri içermesi gerekebilir. Ancak bu bir kez elde edildiğinde, neden unicode tanımlayıcılara da izin vermiyorsunuz? Derleyici kodunuz karakterlerin 7 bit kod olmasına bağlı olmadığı sürece önemli değildir.

Ancak OP tam olarak şu anda: Hintçe konuşan bir Hintli'nin Rusça tanımlayıcıları ve arap yorumlarıyla kodunu koruması gerekiyor. Ne kalite kontrol yapmak gerekiyordu ve yukarıdaki 3 alfabe herhangi birini okuyamıyorum fakir Çinliler için bir kabus!

Bu nedenle, artık bir program tanımlayıcılarının ve yorumlarının ortak bir dilde yazıldığından emin olmak kurumsal bir görevdir. Ben yardım edemem ama bence bu bir süre daha ingilizce olacak.

Dizelerde ve yorumlarda unicode karakterlere izin vermenin çok mantıklı olduğunu düşünüyorum. Lexer ve ayrıştırıcı yine de bunun için unicode'u desteklemek zorundaysa, derleyici yazarı muhtemelen tanımlayıcılarda unicode karakter desteği alır, bu nedenle tanımlayıcılarda yalnızca ASCII karakterlerine izin vermek keyfi bir sınırlama gibi görünecektir.

Bence bu sadece pazarlama amaçlı. Ayrıca, hayatımızı daha da zorlaştırabilir.

Pazarlama argümanları

Çoğu dilde övünen bu çılgın özellik listelerini biliyor musunuz? Genel olarak oldukça işe yaramaz, çünkü dil hakkında çok fazla bilgi vermediği için, ancak bir kenarı ve haçları olan tabloları hızlı bir şekilde giydirmesine izin verir ve X'in Y'den daha fazla kenesi olduğu için haklı olarak sonuca varır. daha iyi ol.

Tanımlayıcılar için Unicode desteği bu satırlardan biridir. Lambda desteği, Genel programlama desteği vb. İle karşılaştırıldığında önemli değil, çok fazla olmayabilir, tabloları çizen insanlar her satırın kalitesini umursamıyorlar, sadece sayıları hakkında.

Ve böylece övünebilirler: "Ah, Y ile tanımlayıcılarınız için Unicode desteğiniz yok! X'te yapıyoruz, bu yüzden öğrenciler için çok daha kolay!"

Erişilebilirlik yanılgısı

Ne yazık ki, erişilebilirlik iddiası yanlıştır.

Oh, anlıyorum ki "diceThrowResult" (evet Fransız'ım) yerine "résultatDuJetDeDé" yazmanın kısa vadede bir kazanç gibi görünebilir ... ancak dezavantajları var!

Programlama iletişim ile ilgilidir

Programınız sadece derleyici için değil (kullandığınız tanımlayıcılar için daha az önem verebilir), aynı zamanda arkadaşlarınız için de geçerlidir. Onu okuyabilmeleri ve anlayabilmeleri gerekiyor.

• okuduğunuzda, kullandığınız karakterleri görselleştirebileceğiniz anlamına gelir, Unicode tüm yazı tipleri tarafından çok iyi desteklenmez
• bunu anlamak, tanımlayıcılara güvenmek anlamına gelir - uzun yorumlarla desteklemediğiniz sürece, ancak bu KURU kuralını ihlal eder.

Tabii ki, sınıf arkadaşınız aynı dili konuşabilir (belli değil, Almanlar, İspanyollar, Libanes ve Chineses ile programlama dersleri aldım) ve öğretmeniniz de ... ama bir şekilde evde üzerinde çalıştığınızı ve aniden yardıma ihtiyacım var: İnternet harika, çözümü bilen binlerce insanla konuşabilirsiniz, sadece sorunuzu anlarlarsa cevap verirler. Ve sen de onların cevabını anlamamız gerekir.

Programlama anlayış gerektirir

Erişilebilirlik ve başlatma, sizin için ağırlaştırmayı yapmak için kendinizi kütüphanelere dayandırmayı gerektirir: ilk ödevinizde konsola okumak / konsoldan yazmak için bir IO katmanını yeniden icat etmek istemezsiniz.

• Bu kütüphaneler hangi dilde yazılıyor?
• Bu kütüphaneler hangi dilde belgeleniyor?

Eğer Arapça Arapça cevap verirseniz, şaşıracağım.

Yalnızca ders itimat sürece yardımcı ve her kütüphane özelliğini bulunanların kapsamlı dokümantasyon, o zaman kullanıma (ve hatta belki de tercüme kütüphaneler) gerekecektir olacak İngilizce dil bir modicrum öğrenmek zorunda. Ama sonra, zaten bu programlama kursuna başlamadan çok önce yaptınız.

İngilizce...

... programcıların (ve çoğu bilim insanının) lingua franca'sı.

Kişi ne kadar erken itiraf ederse ve onunla savaşmak yerine onunla birlikte ilerlerse, o kadar çabuk öğrenir ve ilerler.

Bazıları kaçınılmaz olarak buna karşı yükselecek ve haklı olarak kendi seçtikleri dili konuşma haklarını savunacaklar (genellikle ana dilleri), ancak Babel'in gösterdiği gibi, ne kadar çok dil kullanılırsa, iletişim o kadar zorlaşır.

Hala ...

Evet, defalarca tartışıldığı gibi, bazı Unicode desteği (çoğunlukla semboller), örneğin matematik veya fizik formüllerini koda çevirmek zorunda kalan insanlar için anlayışı büyük ölçüde kolaylaştırabilir. Bazı sembollerin aşırı yüklenmesi dezavantajı vardır, ancak yine de yardımcı olabilir.

Peki neden ?

Söylendiği gibi, pazarlama iddiaları kadar gerçek kullanıcı rahatlığı ile ilgili değil. Ayrıştırıcı zaten Unicode zaten dizeler ve yorumlar için farkında olduğundan, çok kolay, bu yüzden çoğu atlama atın.

Ve bazı kullanıcılar için bir fayda olabilir.

Ama ben şahsen sadece İngilizce tanımlayıcılarla yazılmış kodlarla ilgileneceğim. Kod parçanızla ilgili yardıma ihtiyacınız olup olmadığını ummuyorum ya da kütüphaneniz müthişse ve onu kullanarak çok şey kazanabilirim: eğer anlayamıyorsam, görmezden gelmem gerekecek.

Çince klavyede ASCII tanımlayıcılarını nasıl yazacaksınız? Birkaç dil anahtar kelimesi bir şeydir ve tüm kodunuzu bu şekilde yapmak başka bir şeydir.

Programcılar değişkenlerini istedikleri gibi arama hakkına ve yeteneğine sahip olmalıdır. Hangi dilde olduğunu bilmiyorsun.

Kodunu, başkalarının dillerinden semboller içeren tanımlayıcılarla karıştırdığınızı düşünüyorsanız, o zaman kendi dilinizde sembollerle tanımlayıcılar kullanmak zorunda kaldıklarında ne kadar şaşkın olduklarını tam olarak anladığınızdan eminim .

2007 tarihli PEP 3131 - ASCII Olmayan Tanımlayıcıları Destekleme'ye göre, Gerekçe'nin ilk kısmı şunları belirtmektedir:

Python kodu, dünyada İngilizce'ye aşina olmayan ve hatta Latin yazı sistemini iyi tanıyan birçok kişi tarafından yazılmıştır. Bu tür geliştiriciler, adlandırmak istedikleri kavramın (genellikle yanlış) bir İngilizce çevirisini bulmak yerine, genellikle sınıfları ve işlevleri kendi dillerinde adlarıyla tanımlamak ister. Kendi dillerinde tanımlayıcılar kullanarak, kodun bu dilin konuşmacıları arasında netliği ve sürdürülebilirliği artar.

Henüz başka dilleri araştırmadım, ancak desteği eklemelerinin nedenleri arasında olmalı.

Derleyici verirseniz çok daha kolay hayat (bazılarımız için Neyse) yapacak değil Unicode desteği. Sağdan sola tanımlayıcılar korkunç. Kombine Roma alfabesi ve sağdan sola Unicode tanımlayıcıları daha da kötüdür.

Destek vermemenin kötü yanı, bazı GUI sihirbazlarının bir öğe için girdiğiniz metni alması ve bu metni otomatik olarak öğenin tanımlayıcısı olarak kullanmasıdır. Peki, bu öğelerdeki Unicode metinleriyle tam olarak ne yapacaklardı? Kolay cevap yok, korkarım.

Unicode sağdan sola yorumlar da komik olabilir. Örneğin, VS 2010'da, XML yorumları kodda (doğru olarak) RTL olarak görüntülenir ... ancak tanımlayıcıyı kodun başka bir yerinde çekmek için Intellisense kullandığınızda, araç ipucu (yanlış) LTR görüntüler. Daha iyi, belki de, ilk etapta destek yoksa? Yine, kolay bir çağrı değil.