Statik yazım daha büyük projelerde nasıl yardımcı olur?

Bir komut dosyası programlama dili sitesinin ana sayfasında merak ederken, bu pasajla karşılaştım:

Bir sistem kafanızda kalmayacak kadar büyüdüğünde statik türler ekleyebilirsiniz.

Bu, statik, derlenmiş diller (Java gibi) ve dinamik, yorumlanmış diller (çoğunlukla Python'un daha çok kullanıldığı için, ancak çoğu komut dosyası dili arasında paylaşılan bir "sorun" arasındaki birçok din savaşında, statik olarak şikayetlerden biri olduğunu hatırlattı. yazılan dillerin hayranları, dinamik olarak yazılan dillere göre daha büyük projelere göre iyi ölçeklenmemeleridir, çünkü "bir gün, bir işlevin dönüş türünü unutacaksınız ve statik olarak yazılan dillerle her şeyi aramak zorunda kalacaksınız. msgstr "% s: açıkça bildirildi".

Bunun gibi ifadeleri hiç anlamadım. Dürüst olmak gerekirse, bir işlevin dönüş türünü bildirseniz bile, birçok kod satırı yazdıktan sonra bunu unutabilir ve unutabilirsiniz ve yine de, arama işlevini kullanarak bildirildiği satıra geri dönmeniz gerekecektir. kontrol etmek için metin düzenleyiciniz.

Ek olarak, işlevler bildirildikçe , işlevin çağrıldığı her satırda arama yapmanız gerektiğini type funcname()...bilen type, çünkü funcnamePython ve benzerlerinde sadece aradığınızı def funcnameveya function funcnamesadece bir kez gerçekleştiğini Deklarasyon.

Dahası, REPL'lerle, bir işlevi farklı girişlerle dönüş türü için test etmek önemsizdir, statik olarak yazılan dillerle bazı kod satırları eklemeniz ve bildirilen türü bilmek için her şeyi yeniden derlemeniz gerekir.

Dolayısıyla, statik olarak yazılan dillerin güç noktası olmayan açıkça bir işlevin dönüş türünü bilmek dışında, statik yazım daha büyük projelerde gerçekten nasıl yardımcı olur?

Dahası, REPL'lerle, bir işlevi farklı girdilere sahip dönüş türü için test etmek önemsizdir

Önemsiz değil. Bu önemsiz değil hiç . Bunu önemsiz işlevler için yapmak önemsizdir.

Örneğin, dönüş türünün tamamen giriş türüne bağlı olduğu bir işlevi önemsiz bir şekilde tanımlayabilirsiniz.

getAnswer(v) {
 return v.answer
}

Bu durumda, getAnswergerçekten değil sahip tek dönüş türü. Dönüş türünün ne olduğunu öğrenmek için bunu bir örnek girdi ile çağıran bir test yoktur. Her zaman asıl argümana bağlı olacaktır . İşlem esnasında.

Ve bu, örneğin veritabanı aramaları yapan işlevleri bile içermez. Veya kullanıcı girişine göre bir şeyler yapın. Veya elbette dinamik bir tür olan global değişkenlere bakın. Veya rasgele durumlarda dönüş türlerini değiştirin. Her bir bireysel işlevi her seferinde manuel olarak test etme ihtiyacından bahsetmiyoruz bile.

getAnswer(x, y) {
   if (x + y.answer == 13)
       return 1;
   return "1";
}

Temel olarak, genel durumda işlevin dönüş türünü kanıtlamak tam anlamıyla matematiksel olarak imkansızdır (Durma Sorunu). Geri dönüş türünü garanti etmenin tek yolu , girişi kısıtlamaktır, böylece bu soruya cevap vermek, kanıtlanamayan programları devre dışı bırakarak Durdurma Sorunu alanına girmez ve statik yazmanın yaptığı budur.

Ek olarak, işlevler funcname () ... ile bildirildiğinden, türü bilmeksizin, işlevin çağrıldığı her satırda arama yapmanız gerekecektir, çünkü yalnızca funcname'i biliyorsunuz, Python ve benzerlerinde sadece bildirimde yalnızca bir kez gerçekleşen def işlev adını veya işlev işlev adını arayın.

Statik olarak yazılan dillerde "araçlar" adı verilen şeyler vardır. Bunlar, kaynak kodunuzla bir şeyler yapmanıza yardımcı olan programlardır. Bu durumda, Resharper sayesinde basitçe sağ tıklayıp Tanıma Git. Veya klavye kısayolunu kullanın. Ya da sadece fareyle üzerine gelin ve bana bu türlerin ne olduğunu söyleyecek. En ufak tefek dosyaları umursamıyorum. Tek başına bir metin düzenleyici, program kaynak kodunu düzenlemek için acıklı bir araçtır.

Bellekten, def funcnameişlev keyfi olarak yeniden atanabileceğinden, Python'da yeterli olmazdı. Veya birden fazla modülde tekrar tekrar ilan edilebilir. Veya derslerde. Vb.

ve yine de kontrol etmek için metin düzenleyicinizin arama işlevini kullanarak bildirildiği satıra geri dönmeniz gerekecektir.

İşlev adı için dosyaları aramak, asla gerekmemesi gereken korkunç bir ilkel işlemdir. Bu, ortamınızın ve aletlerinizin temel bir başarısızlığını temsil eder. Python'da bir metin aramasına ihtiyaç duymayı düşünmeniz bile Python'a karşı büyük bir nokta.

Yıllar içinde değişen birçok programcı ile bir proje düşünün. Bunu korumak zorundasın. Bir işlevi var

getAnswer(v) {
 return v.answer
}

Yeryüzünde ne yapar? Nedir v? Öğe answernereden geliyor?

getAnswer(v : AnswerBot) {
  return v.answer
}

Şimdi biraz daha bilgimiz var; bir tür ihtiyacı var AnswerBot.

Sınıf temelli bir dile gidersek şunu söyleyebiliriz:

class AnswerBot {
  var answer : String
  func getAnswer() -> String {
    return answer
  }
}

Şimdi bir değişken tipine sahip olabiliriz AnswerBotve yöntemi çağırabiliriz getAnswerve herkes ne yaptığını bilir. Herhangi bir değişiklik, herhangi bir çalışma zamanı testi yapılmadan önce derleyici tarafından yakalanır. Başka birçok örnek var ama belki de bu size fikir veriyor?

Kararınızı bulanıklaştırabilecek büyük statik projelerle çalışma konusunda birkaç yanlış anlaşmanız var gibi görünüyor. İşte bazı işaretçiler:

bir işlevin dönüş türünü bildirseniz bile, birçok kod satırı yazdıktan sonra bunu unutabilir ve unutabilirsiniz ve yine de metin düzenleyicinizin arama işlevini kullanarak bildirildiği satıra geri dönmeniz gerekecektir. kontrol et.

Statik olarak yazılan dillerle çalışan çoğu kişi, dil için bir IDE veya dile özgü araçlarla entegrasyonu olan akıllı bir düzenleyici (vim veya emacs gibi) kullanır. Bu tür araçlarda genellikle bir işlev türünü bulmanın hızlı bir yolu vardır. Örneğin, bir Java projesinde Eclipse ile, genellikle bir yöntem türünü bulmanın iki yolu vardır:

• 'Bu' dışında başka bir nesne üzerinde bir yöntem kullanmak isterseniz, bir başvuru ve bir nokta (örneğin someVariable.) yazın ve Eclipse türünü arar ve bu türde someVariabletanımlanan tüm yöntemlerin bir açılan listesini sağlar; Listeyi aşağı kaydırdığımda, seçildiklerinde her birinin türü ve belgeleri görüntülenir. Dinamik bir dil ile bunu başarmanın çok zor olduğuna dikkat edin, çünkü editörün türünün ne olduğunu belirlemek zor (veya bazı durumlarda imkansızdır) someVariable, bu yüzden doğru listeyi kolayca oluşturamaz. Bir yöntem kullanmak istersem thisaynı listeyi almak için ctrl + space tuşlarına basabilirim (bu durumda dinamik diller için bu kadar zor değil).
• Zaten belirli bir yönteme yazılmış bir başvurum varsa, fare imlecini üzerinde hareket ettirebilirim ve yöntemin türü ve belgeleri araç ipucunda görüntülenir.

Gördüğünüz gibi, bu, dinamik diller için mevcut olan tipik araçlardan biraz daha iyidir ( bazılarının IDE işlevselliği olduğu için dinamik dillerde imkansız olduğu anlamına gelmez - smalltalk akla gelen bir şeydir - ancak dinamik bir dil ve bu nedenle kullanılabilir olma olasılığı daha düşüktür).

Ek olarak, işlevler funcname () ... ile bildirildiğinden, türü bilmeksizin, işlevin çağrıldığı her satırda arama yapmanız gerekecektir, çünkü yalnızca funcname'i biliyorsunuz, Python ve benzerlerinde sadece bildirimde yalnızca bir kez gerçekleşen def işlev adını veya işlev işlev adını arayın.

Statik dil araçları genellikle semantik arama yetenekleri sağlar, yani bir metin araması yapmaya gerek kalmadan belirli sembollerin tanımını ve referanslarını tam olarak bulabilirler. Örneğin, bir Java projesi için Eclipse kullanarak, metin düzenleyicisindeki bir sembolü vurgulayabilir ve sağ tıklayabilir ve bu işlemlerden birini gerçekleştirmek için 'tanımlamaya git' veya 'referansları bul'u seçebilirim. Bir işlev tanımının metnini aramanız gerekmez, çünkü düzenleyiciniz tam olarak nerede olduğunu biliyor.

Ancak, bunun tersi, bir yöntem tanımını metne göre aramanın, önerdiğiniz gibi büyük bir dinamik projede gerçekten iyi çalışmadığıdır, çünkü böyle bir projede aynı ada sahip birden çok yöntem kolayca olabilir ve muhtemelen hiç hangisini çağırdığınızı netleştirmek için hazır araçlar (çünkü bu tür araçların en iyi şekilde yazılması zordur veya genel durumda imkansızdır), bu yüzden elle yapmanız gerekir.

Dahası, REPL'lerle, bir işlevi farklı girdilere sahip dönüş türü için test etmek önemsizdir

Statik olarak yazılan bir dil için REPL olması imkansız değildir. Haskell akla gelen bir örnektir, ancak diğer statik olarak yazılmış diller için de REPL'ler vardır. Ancak asıl nokta, statik bir dilde bir işlevin dönüş türünü bulmak için kod yürütmeniz gerekmemesidir - hiçbir şey çalıştırmaya gerek kalmadan muayene ile belirlenebilir.

statik olarak yazılmış dillerle, bazı kod satırları eklemeniz ve beyan edilen türü bilmek için her şeyi yeniden derlemeniz gerekir.

Şansınız, bunu yapmanız gerekse bile, her şeyi yeniden derlemek zorunda kalmayacaksınız . Çoğu modern statik dilde, kodunuzun yalnızca küçük bir bölümünü derleyen artımlı derleyiciler bulunur, böylece tür hataları için neredeyse anında geri bildirim alabilirsiniz. Örneğin Eclipse / Java, siz yazarken yazım hatalarını vurgulayacaktır .

1. Çünkü statik olarak yazılmış diller için statik denetleyiciler daha kolaydır.
   • Çıplak bir minimumda, dinamik dil özelliği olmadan, derlerse, çalışma zamanında çözülmemiş işlevler yoktur. Bu ADA projelerinde ve mikrodenetleyicilerde C yaygındır. (Mikrodenetleyici programları bazen büyür ... yüzlerce kloc gibi.)
2. Statik derleme referans kontrolleri, statik bir dilde derleme zamanında da kontrol edilebilen işlev değişmezlerinin bir alt kümesidir.
3. Statik diller genellikle daha fazla referans şeffaflığına sahiptir. Sonuç olarak, yeni bir geliştirici tek bir dosyaya dalabilir ve neler olduğunu anlayabilir ve kod tabanındaki tüm tuhaf şeyleri bilmek zorunda kalmadan bir hatayı düzeltebilir veya küçük bir özellik ekleyebilir.

Geliştiricilerin temel dil işlevlerini çalışma zamanında yeniden tanımladıkları say, javascript, Ruby veya Smalltalk ile karşılaştırın. Bu, büyük projeksiyonu anlamayı zorlaştırır.

Daha büyük projelerin sadece daha fazla insanı değil, daha fazla zamanı vardır. Herkesin unutması veya ilerlemesi için yeterli zaman.

Anekdot olarak, bir tanıdımın Lisp'te güvenli bir "Yaşam İçin İş" programı var. Takım dışında hiç kimse kod tabanını anlayamaz.

Bunun gibi ifadeleri hiç anlamadım. Dürüst olmak gerekirse, bir işlevin dönüş türünü bildirseniz bile, birçok kod satırı yazdıktan sonra bunu unutabilir ve unutabilirsiniz ve yine de, arama işlevini kullanarak bildirildiği satıra geri dönmeniz gerekecektir. kontrol etmek için metin düzenleyiciniz.

Geri dönüş türünü unutmakla ilgili değil - bu her zaman olacak. Bu, aracın dönüş türünü unuttuğunuzu size bildirebilmesiyle ilgilidir.

Ek olarak, işlevler funcname()...türle bildirildiğinden, türü bilerek, işlevin çağrıldığı her satırda arama yapmanız gerekecektir, çünkü yalnızca biliyorsunuz funcname, Python ve benzerlerinde yalnızca arayabileceğiniz def funcnameveya function funcnameyalnızca bir kez gerçekleşen , deklarasyonda.

Bu, statik yazımla tamamen ilgisiz bir sözdizimi meselesidir.

C ailesi sözdizimi, elinizde özel araçlar olmadan bir bildiri aramak istediğinizde gerçekten düşmancadır. Diğer dillerde bu sorun yoktur. Rust'un bildirim sözdizimine bakın:

fn funcname(a: i32) -> i32

Dahası, REPL'lerle, bir işlevi farklı girişlerle dönüş türü için test etmek önemsizdir, statik olarak yazılan dillerle bazı kod satırları eklemeniz ve beyan edilen türü bilmek için her şeyi yeniden derlemeniz gerekir.

Herhangi bir dil yorumlanabilir ve herhangi bir dilde REPL olabilir.

Dolayısıyla, statik olarak yazılan dillerin güçlü bir noktası olmayan bir işlevin dönüş türünü bilmek dışında, statik yazım daha büyük projelerde gerçekten nasıl yardımcı olur?

Soyut bir şekilde cevaplayacağım.

Bir program çeşitli işlemlerden oluşur ve geliştiricinin yaptığı bazı varsayımlar nedeniyle bu işlemler oldukları gibi düzenlenir.

Bazı varsayımlar üstü kapalı, bazıları açıktır. Bazı varsayımlar yanlarındaki bir operasyonla, bazıları da onlardan uzak bir operasyonla ilgilidir. Bir varsayım, gerçeğe uygun değerinin önemli olduğu yerlere açıkça ve mümkün olduğunca yakın olarak ifade edildiğinde tanımlanması daha kolaydır.

Bir hata, programda var olan ancak bazı durumlar için geçerli olmayan bir varsayımın tezahürüdür. Bir hatayı takip etmek için hatalı varsayımı tanımlamamız gerekir. Hatayı kaldırmak için ya bu varsayımı programdan kaldırmamız ya da varsayımın gerçekten geçerli olması için bir şeyi değiştirmemiz gerekir.

Varsayımları iki türe ayırmak istiyorum.

Birinci tür, programın girdilerine bağlı olarak, tutabilecek ya da tutamayacak varsayımlardır. Bu tür hatalı bir varsayımı tanımlamak için, programın tüm olası girişleri alanında arama yapmamız gerekir. Eğitimli tahminler ve rasyonel düşünme kullanarak sorunu daraltabilir ve daha küçük bir alanda arama yapabiliriz. Ama yine de, bir program biraz büyüdükçe, başlangıç ​​girdi alanı muazzam bir oranda büyüyor - tüm pratik amaçlar için sonsuz olarak kabul edilebileceği noktaya kadar.

İkinci tür, tüm girdiler için kesinlikle geçerli olan veya tüm girdiler için kesinlikle hatalı olan varsayımlardır. Bu tür bir varsayımı hatalı olarak tespit ettiğimizde, programı çalıştırmamız veya herhangi bir girişi test etmemiz bile gerekmez. Bu tür bir varsayımı doğru olarak tespit ettiğimizde, bir hatayı ( herhangi bir hatayı) izlerken ne kadar dikkatli olacağımızdan daha az şüpheleniriz . Bu nedenle, bu türden olabildiğince fazla varsayımlara sahip olmanın değeri vardır.

İkinci kategoriye (her zaman doğru veya her zaman yanlış, girdilerden bağımsız) bir varsayım koymak için, varsayımın yapıldığı yerde minimum miktarda bilgiye ihtiyacımız vardır. Bir programın kaynak kodunda, bilgi oldukça hızlı bir şekilde eski hale gelir (örneğin, birçok derleyici süreçler arası analiz yapmaz, bu da herhangi bir çağrıyı çoğu bilgi için zor bir sınır haline getirir). Gerekli bilgileri taze (geçerli ve yakın) tutmak için bir yola ihtiyacımız var.

Bunun bir yolu, bu bilgilerin kaynağının tüketileceği yere olabildiğince yakın olmasını sağlamaktır, ancak bu çoğu kullanım durumunda pratik olmayabilir. Başka bir yol da bilgileri sık sık tekrarlamak ve kaynak koddaki ilgisini yenilemektir.

Tahmin edebileceğiniz gibi, statik türler tam olarak budur - kaynak koduna dağılmış tip bilgisi işaretleri. Bu bilgi, ikinci kategoride tür doğruluğu ile ilgili varsayımların çoğunu koymak için kullanılabilir, yani hemen hemen her işlem tür uyumluluğuna göre her zaman doğru veya her zaman yanlış olarak sınıflandırılabilir.

Türlerimiz yanlış olduğunda, analiz, hatayı geç değil erken dikkatimize getirerek zaman kazandırır. Türlerimiz doğru olduğunda, analiz, bir hata oluştuğunda, tür hatalarını hemen dışlayabilmemizi sağlayarak bize zaman kazandırır.

Eski atasözü "çöp içeri, çöp dışarı" hatırlıyorsunuz, iyi, statik yazmayı önlemek için yardımcı olan budur. Bu evrensel bir her derde deva değil, bir rutinin ne tür verileri kabul ettiği ve geri döndüğü konusundaki katılık, onunla doğru çalıştığınıza dair bir güvenceye sahip olduğunuz anlamına gelir.

Bu nedenle, bir tamsayı döndüren bir getAnswer yordamı, dizeye dayalı bir çağrıda kullanmaya çalıştığınızda yararlı olmaz. Statik yazma zaten size dikkat etmenizi söylüyor, muhtemelen bir hata yaptığınızı. (ve emin olun, daha sonra geçersiz kılabilirsiniz, ancak tam olarak ne yaptığınızı bilmeniz ve bir döküm kullanarak kodda belirtmeniz gerekir. Genel olarak, bunu yapmak istemezsiniz - kare bir delik içine yuvarlak peg sonunda asla iyi çalışır)

Şimdi karmaşık türleri kullanarak, cevher işlevselliğine sahip bir sınıf oluşturarak daha ileriye götürebilirsiniz, bunları geçmeye başlayabilirsiniz ve aniden programınızda daha fazla yapı elde edersiniz. Yapılandırılmış programlar, doğru çalışmayı ve sürdürmeyi çok daha kolay olan programlardır.