Neden hemen hemen tüm modern programlama dillerinde (Go, Rust, Kotlin, Swift, Scala, Nim, hatta Python'un son versiyonları) türler önceden değişken değişken bildiriminde değişken isminden sonra gelir?

Neden x: int = 42ve değil int x = 42?
İkincisi eskisinden daha okunaklı değil mi?
Bu sadece bir trend mi, yoksa bu çözümün arkasında gerçekten anlamlı sebepler var mı?

Bahsettiğiniz dillerin tümü, tür çıkarımını desteklemektedir ; bu , türün, bu dillerdeki bildirimin isteğe bağlı bir parçası olduğu anlamına gelir ; çünkü, kolayca tanımlanabilen bir türden bir başlatma ifadesi sağladığınızda, kendileri dolduracak kadar akıllıdırlar.

Bu önemlidir, çünkü bir ifadenin isteğe bağlı bölümlerini daha sağa koymak, ayrıştırma belirsizliğini azaltır ve bu kısmı kullanan ifadelerle tutarlı olmayan ifadeler arasındaki tutarlılığı artırır. varİsteğe bağlı maddelere girmeden önce anahtar kelimenin ve değişken adının zorunlu olduğunu bildiğinizde bir bildirimi ayrıştırmak daha kolaydır . Teoride, bilgisayarlar daha kolay ayrıştırmak için yapmak tüm bunları gerektiği de insanlar için genel okunabilirliği artırmak, ama bu çok daha tartışılır.

Aşağıdaki gibi C ++ gibi bir "non-modern" dil vardır tüm isteğe bağlı tip düzenleyiciler, düşünün, bu argüman özellikle güçlü olur *göstericiler için, &referanslar için const, volatilevb. Birden beyanlar için virgül atmak sonra, aşağıdaki gibi bazı gerçekten garip belirsizlikler olsun başlamak int* a, b;yapmıyor bbir işaretçi.

C ++ bile şimdi "sağdaki tip" bildirimlerini destekliyor auto x = int{ 4 };ve bazı avantajları var .

Neden hemen hemen tüm modern programlama dillerinde (Go, Rust, Kotlin, Swift, Scala, Nim, hatta en son Python) tipleri değişken bildiriminden sonra gelir, önceden değil?

Senin öncül iki cephesinde kusurlu:

• Tanımlayıcıdan önce türüne sahip yeni-ish programlama dilleri vardır . C♯, D veya Ceylon, örneğin.
• Tanımlayıcıdan sonra türün olması yeni bir fenomen değildir, en azından Pascal'a (1968–1969'da tasarlandı, 1970'te yayınlandı) geri döndü, ama aslında ~ 1902'yi başlatan matematiksel tip teorisinde kullanıldı. Ayrıca ML (1973), CLU (1974), Hope (1970'ler), Modula-2 (1977–1985), Ada (1980), Miranda (1985), Caml (1985), Eiffel (1985), Oberon'da kullanıldı. (1986), Modula-3 (1986-1988) ve Haskell (1989).

Pascal, ML, CLU, Modula-2 ve Miranda'nın hepsi çok etkili dillerdi, bu yüzden bu tip beyanların stilinin popüler kalması şaşırtıcı değil.

Neden x: int = 42ve değil int x = 42? İkincisi eskisinden daha okunaklı değil mi?

Okunabilirlik bir aşinalık meselesidir. Şahsen, Çince’yi okunamayan buluyorum ama görünüşe göre, Çinliler yok. Pascal’ı okulda öğrenmiş, Eiffel, F♯, Haskell ve Scala’ya bakmış ve TypeScript, Fortress, Go, Rust, Kotlin, İdris, Frege, Agda, ML, Ocaml…… .

Bu sadece bir trend mi yoksa böyle bir çözümün arkasındaki gerçekten anlamlı sebepler var mı?

Eğer bir trendse, oldukça ısrarcıdır: Bahsettiğim gibi, matematikte yüz yıl öncesine dayanır.

Tanımlayıcıdan sonra yazı tipine sahip olmanın en önemli avantajlarından biri, çıkarımın istenmesi durumunda yazıyı bırakmanın kolay olmasıdır. Eğer beyanlarınız şöyle görünüyorsa:

val i: Int = 10

O zaman türünü dışarıda bırakmak ve bunun gibi çıkarımı yapmak çok önemlidir:

val i = 10

Bununla birlikte, tür şöyle tanımlayıcıdan önce gelirse:

Int i = 10

Ardından, çözümleyicinin bir ifadeyi bildirimden ayırması zorlaşmaya başlar:

i = 10

Dil tasarımcılarının genellikle ortaya çıkardığı çözüm, tür yerine yazılması gereken bir "tür yazmak istemiyorum" anahtar sözcüğünü tanıtmaktır:

var  i = 10; // C♯
auto i = 10; // C++

Fakat bu aslında pek bir anlam ifade etmiyor: temel olarak açıkça bir tür yazmadığınızı söyleyen bir tür yazmanız gerekiyor. Ha? Sadece dışarıda bırakmak çok daha kolay ve daha mantıklı olurdu, ama bu gramerin daha karmaşık olmasını sağlıyor.

(Ve C'deki fonksiyon işaretçi tipleri hakkında konuşmayalım .)

Yukarıda belirtilen dillerin birçoğunun tasarımcıları bu konuda tartıştılar:

• Go FAQ (ayrıca bakınız: Go Beyanı Sözdizimi ):

  Bildirimler neden geriye doğru?

  Yalnızca C'ye alışırsanız geriye doğrular. C de, bir değişkenin türünü belirten bir ifade gibi bildirildiği, bunun iyi bir fikir olduğu ifade edilir, ancak tür ve ifade dilbilgileri çok iyi karışmaz ve sonuçlar kafa karıştırıcı olabilir; fonksiyon göstericileri düşünün. Go, çoğunlukla ifadeyi ve yazım sözdizimini ayırır ve işleri basitleştirir ( *işaretçiler için önek kullanmak , kuralı ispatlayan bir istisnadır). C’de beyan

  int* a, b;
  

  abir işaretçi olduğunu beyan eder b; Go'da

  var a, b *int
  

  ikisinin de işaretçi olduğunu açıklar. Bu daha net ve daha düzenli. Ayrıca, :=kısa bir beyan formu tam değişken bildirimi ile aynı düzeni mevcut gerektiğini savunur :=böylece

  var a uint64 = 1
  

  aynı etkiye sahiptir

  a := uint64(1)
  

  Ayrıştırma, yalnızca ifadede kullanılan dilbilgisi olmayan türler için ayrı bir dilbilgisi olmasıyla da kolaylaştırılmıştır; gibi anahtar kelimeler funcve chanişleri açık tutun.

• Kotlin SSS :

  Neden sağda tip beyanları var?

  Kodu daha okunabilir hale getirdiğine inanıyoruz. Ayrıca, bazı güzel sözdizimsel özellikleri de sağlar. Örneğin, tür ek açıklamalarını dışarıda bırakmak kolaydır. Scala ayrıca oldukça iyi olduğunu kanıtladı, bu bir sorun değil.

• Scala'da Programlama :

  Java'dan büyük sapma, tür ek açıklamalarının sözdizimi ile ilgilidir - Java'da " variable: Type" yerine " Type variable" dir. Scala'nın postfix tipi sözdizimi Pascal, Modula-2 veya Eiffel'i andırıyor. Bu sapmanın temel nedeni, genellikle bir değişkenin türünü veya bir yöntemin dönüş türünü atlamanıza izin veren tür çıkarımı ile ilgilidir. " variable: Type" Sözdizimini kullanarak bu kolaydır - sadece iki nokta üst üste ve türünü bırakın. Ancak C tarzı " Type variable" sözdiziminde türden basitçe çıkamazsınız; tanımı tanımlamak için artık bir işaretleyici olmaz. Eksik bir tür için yer tutucu olması için alternatif bir anahtar kelimeye ihtiyacınız olacak (bazı tür çıkarımlar yapan C uses 3.0, varbu amaç için kullanır ). Böyle bir alternatif anahtar kelime, Scala'nın yaklaşımından daha geçici ve daha az düzenli hissediyor.

Not: Ceylon tasarımcıları ayrıca neden önek tipi sözdizimi kullandıklarını da belgelemiştir :

Postfix tipi açıklama yerine önek

Niçin C ve Java'yı, önce açıklama adından sonra Pascal ve ML yerine tür ek açıklamalarını koymakta?

Çünkü bunu düşünüyoruz:

shared Float e = ....
shared Float log(Float b, Float x) { ... }

Okumak bundan daha kolay:

shared value e: Float = .... 
shared function log(b: Float, x: Float): Float { ... }

Ve biz sadece bir insanın başka türlü nasıl düşünebileceğini anlamıyoruz!

Şahsen ben onların "argümanını" diğerlerinden daha ikna edici buluyorum.

Pascal bu arada bunu da yapıyor ve yeni bir dil değil. Yine de sıfırdan tasarlanmış bir akademik dildi.

Değişken ismi ile başlamanın anlamsal olarak daha açık olduğunu söyleyebilirim. Tip sadece teknik bir detay. Sınıfınızı olduğu gibi gerçekliğin modeli gibi okumak istiyorsanız, varlıklarınızın adlarını ve teknik uygulamalarını en sonda tutmak mantıklıdır.

C # ve java, C'den kaynaklanır, bu nedenle tecrübeli programcının kafasını karıştırmamak için "önceki tekniğe" saygı duymaları gerekirdi.

Neden x: int = 42ve değil int x = 42? İkincisi eskisinden daha okunaklı değil mi?

Bu kadar basit bir örnekte, çok fazla fark yok, ancak biraz daha karmaşık hale getirelim: int* a, b;

Bu, C dilinde geçerli ve geçerli bir beyandır, ancak olması gerektiği gibi sezgisel göründüğü gibi yapmaz. Görünüşe göre iki tip değişken ilan ediyoruz int*, fakat aslında bir int*ve bir tane ilan ediyoruz int.

Diliniz yazıyı değişken isimlerinden sonraki açıklamalarına koyarsa , bu problemin üstesinden gelmek imkansızdır.