Herhangi bir programlama dilinde karşılaştığınız en büyük tasarım hatası nedir? [kapalı]

Tüm programlama dilleri tasarım kusurlarına sahiptir çünkü tek bir dil, çoğu (hepsi?) Diğer şeylerde olduğu gibi mükemmel olamaz. Bir kenara, bir programlama dilinde hangi tasarım hatası, bir programcı olarak geçmişiniz boyunca sizi en çok rahatsız etti?

Bir dil, sadece belirli bir şey için tasarlanmadığı için "kötü" ise, bir tasarım kusuru değil, tasarımın bir özelliği olduğunu unutmayın ; Bir dil tasarlandığı şey için uygun değilse, bu elbette tasarımdaki bir kusurdur. Uygulamaya özgü şeyler ve başlık altındaki şeyler de sayılmaz.

En büyük sıkıntılarımdan biri, switchkullanmayı unutursanız C'den türetilmiş dillerdeki davaların varsayılan olarak bir sonraki davaya düşmesidir break. Bunun çok düşük seviyeli kodda (örneğin, Duff's Device ) faydalı olduğunu biliyorum, ancak genellikle uygulama seviyesi kodu için uygun değildir ve yaygın bir kodlama hatası kaynağıdır.

1995 yılında, ilk kez Java'nın ayrıntılarını okuduğumda, switchifade hakkındaki kısma geldiğimde varsayılan düşme davranışını korudukları için çok hayal kırıklığına uğradığımı hatırlıyorum . Bu sadece başka bir isimle switchyüceltilir goto.

C-türevlerinde =atama ve ==eşitlik testi kullanımından hiç hoşlanmam . Karışıklık ve hata potansiyeli çok yüksek. Ve beni ===Javascript'te başlatmaya bile gerek yok .

Daha iyisi, :=atama ve =eşitlik testi için olurdu . Anlambilim, bugünkü ile tam olarak aynı olabilirdi, burada atama aynı zamanda bir değer üreten bir ifadedir.

Seçimi +ikisi için JavaScript eklenmesi ve karakter dizisi birleştirme korkunç bir hataydı. Değerler yazılmamış olduğundan, bu +, her işlemcinin tam içeriğine bağlı olarak eklenip eklenmeyeceğini belirleyen Bizans kurallarına yol açar .

$Dize bitiştirme gibi tamamen yeni bir operatör tanıtmak başlangıçta kolay olurdu .

Javascript’i varsayılan olarak global olarak ana konuya, JSLint veya benzeri kullanmıyorsanız sık sık kaynaklara neden buluyorum.

C ve C ++ 'daki önişlemci muazzam bir kirleticidir, elek gibi sızan soyutlamalar oluşturur, sıçanların #ifdefifade yuvaları aracılığıyla spagetti kodunu teşvik eder ALL_CAPSve sınırlamaları etrafında çalışmak için korkunç derecede okunamayan isimler gerektirir . Bu sorunların kökü, sözdizimsel veya anlamsal seviyeden ziyade metin düzeyinde işleyişidir. Çeşitli kullanım durumları için gerçek dil özellikleri ile değiştirilmiş olması gerekirdi. Bazı örnekler, kuşkusuz bunlardan bazıları C ++, C99 veya resmi olmayan ancak fiili standart uzantılarla çözülmüş olsa da :

• #include Gerçek bir modül sistemi ile değiştirilmeliydi.

• Satır içi işlevler ve şablonlar / jenerik, işlev çağrısı kullanım durumlarının çoğunun yerini alabilir.

• Bu tür sabitleri bildirmek için bir çeşit tezahür / derleme zaman sabiti özelliği kullanılabilir. D'nin enum uzantıları burada harika çalışıyor.

• Gerçek sözdizimi ağacı düzeyindeki makrolar çok çeşitli kullanım durumlarını çözebilir.

• Dize karışımları , kod enjeksiyon kullanım durumu için kullanılabilir.

• static ifveya versionifadeler şartlı derleme için kullanılabilir.

Kişi yüzlerce dilde yüzlerce hatayı listeleyebilir, ancak IMO dil tasarımı açısından yararlı bir alıştırma değildir.

Niye ya?

Çünkü bir dilde yanlış olacak bir şey başka bir dilde hata olmaz. Örneğin:

• C'yi yönetilen (yani toplanan çöpler) bir dil yapmak ya da ilkel türleri ayırmak kullanışlılığını yarı portatif düşük seviyeli bir dil olarak sınırlar.
• Java'ya C tarzı bellek yönetimi eklemek (örneğin, performans endişelerini gidermek).

Orada olan tarihsel bağlam öğrenilecek dersler, ama dersler nadiren kesin vardır ve onları anlamaya teknik dengeler anlamalısın ... vb. (Örneğin, Java’nın jenerik teknolojisinin uygulanması, geriye dönük uyumluluğu korumak için geçersiz kılan bir iş gereksiniminin bir sonucudur .)

IMO, eğer yeni bir dil tasarlama konusunda ciddiysen, gerçekten geniş bir dil yelpazesi kullanmalısın (ve tarihsel dilleri çalışmalısın ...) ve hataların ne olduğuna karar vermelisin. Ve bu dillerin her birinin belirli bir ihtiyacı karşılamak için belirli bir tarihsel bağlamda tasarlandığını aklınızda bulundurmanız gerekir.

Genel olarak öğrenilecek dersler varsa “meta” seviyesindedirler:

• Her amaç için ideal bir programlama dili tasarlayamazsınız.
• Hata yapmaktan kaçınamazsınız ... özellikle de arka görüş alanlarına bakıldığında.
• Pek çok hata dilinizi kullananlar için düzeltmek için çok acı verici.
• Hedef kitlenizin geçmişini ve becerilerini göz önünde bulundurmalısınız; yani mevcut programcılar.
• Herkesi memnun edemezsin.

C ve C ++ : yok Tüm bu tamsayı türleri ortalama şey.

Özellikle char. Metin mi yoksa küçük bir tamsayı mı? Metinse, "ANSI" bir karakter mi, yoksa UTF-8 kod birimi mi? Bir tam sayıysa imzalı mı yoksa imzasız mı?

int "yerel" boyutlu bir tamsayı olması gerekiyordu, ancak 64-bit sistemlerde öyle değil.

longbüyük olabilir veya olmayabilir int. Bir işaretçinin boyutu olabilir veya olmayabilir. Derleyici yazarlar için 32-bit veya 64-bit olsun, keyfi bir karardır.

Kesinlikle 1970'lerin bir dili. Unicode'dan önce. 64 bit bilgisayarlardan önce.

null.

Mucidi Tony Hoare, ona "milyar dolarlık hata" diyor .

60'lı yıllarda ALGOL'de tanıtıldı ve günümüzde yaygın olarak kullanılan programlama dillerinin çoğunda var.

OCaml ve Haskell gibi dillerde kullanılan daha iyi bir alternatif, bir belki . Genel fikir, nesne referanslarının, olabileceğinin açık bir göstergesi olmadıkça boş / boş / varolmayan olamayacağıdır.

(Tony alçakgönüllülüğü içinde harika olsa da, neredeyse herkesin aynı hatayı yapabileceğini düşünüyorum, ve o sadece ilk oldu.)

PHP'yi tasarlayanların normal bir klavyeyi kullanmadıklarını, bir colemak klavyeyi kullanmadıklarını, çünkü ne yaptıklarını fark etmeleri gerektiğini hissettim.

Ben bir PHP geliştiricisiyim. PHP yazmak eğlenceli değil.

Who::in::their::right::mind::would::do::this()? ::Operatör tutma vardiya ve daha sonra iki basılmasını gerektirir. Ne kadar enerji kaybı.

Although-> this-> IS-> değil-> çok-> daha iyi. Bu aynı zamanda, iki sembol arasında geçiş varken üç tuşa basılmasını gerektirir.

$last = $we.$have.$the.$dumb.'$'.$character. Dolar işareti muazzam miktarda kullanılır ve ödülün klavyenin en üstüne ve bir üst karakter tuşuna basılmasını gerektirir.

Neden PHP'yi yazmak için çok daha hızlı anahtarlar kullanacak şekilde tasarlayamadılar? Neden we.do.this()varslar sadece bir tuşa basmayı gerektiren - veya hiç olmayan (JavaScript) bir anahtarla başlayamıyor veya sahip değiller ve sadece tüm varlıkları önceden tanımlayın (yine de E_STRICT için yapmam gereken gibi)!

Yavaş bir daktilo değilim - ama bu sadece bir topal tasarım seçimdir.

Masaüstü kullanımı ilham formları içinde asp.net .

Her zaman bir şekerleme hissettim ve yol ya da web aslında nasıl çalıştığını aldı. Neyse ki asp.net-mvc bu ilhamdan dolayı Ruby vb.

Benim için PHP'nin standart kütüphanesindeki adlandırma ve argüman siparişi sözleşmelerinin mutlak eksikliğidir.

Her ne kadar JASS , başvurulan nesne serbest bırakıldıktan / çıkartıldıktan sonra (veya referans kaçak yapar ve birkaç byte hafıza kaybedilirse) referansları geçersiz kılma zorunluluğu olsa da, daha ciddidir, ancak JASS tek amaçlı bir dil olduğundan, o kadar da kritik değildir.

Karşılaştığım en büyük tasarım hatası, python'un başlangıçta python 3.x gibi tasarlanmamış olması.

C dizisinde bozunma ve sonuç olarak C ++.

Java'da ilkel türler.

java.lang.ObjectTeorik bir bakış açısıyla dil şartnamesinin ek karmaşıklığına yol açan ve pratik bir bakış açısıyla koleksiyon kullanımını son derece sıkıcı hale getiren her şeyin bir soydan geldiği ilkesini çiğniyorlar.

Otomatik kutulama pratik dezavantajları hafifletmeye yardımcı oldu, ancak spesifikasyonları daha da karmaşık hale getirme ve büyük bir yağ muz derisi getirme pahasınayken: Artık basit bir aritmetik işlem gibi görünen şeyden boş bir gösterici istisnası alabilirsiniz.

Perl'i en iyi tanıyorum, o yüzden seçeceğim.

Perl birçok fikir denedi. Bazıları iyiydi. Bazıları kötüydü. Bazıları orjinaldi ve iyi bir nedenden ötürü kopyalanamadı.

Birincisi bağlam fikri - her işlev çağrısı listede veya skalar bağlamında gerçekleşir ve her bağlamda tamamen farklı şeyler yapabilir. Http://use.perl.org/~btilly/journal/36756 de işaret ettiğim gibi, bu her API'yi karmaşıklaştırıyor ve Perl kodunda sık sık ince tasarım sorunlarına yol açıyor.

Bir sonraki, sözdizimi ve veri türlerini bu kadar tamamen bağlama fikridir. Bu, nesnelerin diğer veri türleri gibi maskelenmesine izin vermek için bağın icat edilmesine yol açar. (Aşırı yük kullanarak da aynı etkiyi elde edebilirsiniz, ancak kravat Perl'de daha yaygın bir yaklaşımdır.)

Pek çok dil tarafından yapılan bir başka yaygın hata, sözlükten ziyade dinamik kapsam belirleme ile başlamaktır. Bu tasarım kararını daha sonra geri almak zordur ve uzun süreli siğillere yol açar. Perl'deki bu siğillerin klasik açıklaması http://perl.plover.com/FAQs/Namespaces.html'dir . Bunun Perl'in ourdeğişkenler ve staticdeğişkenler eklemeden önce yazıldığını unutmayın .

İnsanlar, statik ve dinamik yazmaya karşı yasal olarak aynı fikirde değiller. Ben şahsen dinamik yazmayı severim. Ancak, yazım hatalarının yakalanmasına izin verecek kadar yapıya sahip olmak önemlidir. Perl 5 bununla iyi bir iş çıkarır. Fakat Perl 1-4 bunu yanlış anladı. Diğer birkaç dilde de aynı şeyi yapan tiftik damaları vardır. Tüy bırakma kontrolünü zorlama konusunda iyi olduğunuz sürece, bu kabul edilebilir.

Daha fazla kötü fikir (çok sayıda) arıyorsanız PHP'yi öğrenin ve geçmişini inceleyin. En sevdiğim hatam (uzun zaman önce çok fazla güvenlik açığına yol açtığı için düzeltildi), herhangi bir değişkeni form parametrelerine geçirerek herhangi bir değişkeni ayarlamaya izin veriyordu. Ancak bu tek hatadan uzak.

JavaScripts kod blokları ve nesne değişmezleri için belirsizlik.

  {a:b}

abir etiket ve bbir ifade olan bir kod bloğu olabilir ; veya adeğeri olan bir niteliği olan bir nesneyi tanımlayabilir.b

FORTRAN'a ve boşluklara duyarsızlığa geri döneceğim.

Şartnameyi bozdu. ENDKart uygun olarak, "son" olan bir kart yerine, 'E' olan bir kart, bir N '', ve sütun 7-72 bir sırada bir 'D', ve diğer bir nonblanks olarak tanımlanabilir zorunda sütunlar ve başka hiçbir şey.

Kolay sözdizimsel karışıklığa yol açtı. DO 100 I = 1, 10bir döngü kontrol ifadesiyken, DO 100 I = 1. 101.1 değerini bir değişkene atanmış bir ifadeydi DO10I. (Değişkenlerin bildirilmeden yaratılabileceği gerçeği, ilk harflerine göre türleri, buna katkıda bulundu.) Diğer dillerin aksine, belirsizliği gidermek için belirteçleri ayırmak için boşluk kullanmanın bir yolu yoktu.

Ayrıca başkalarının kafa karıştırıcı kod yazmasına izin verdi. FORTRAN'ın bu özelliğinin bir daha asla tekrarlanmamasının nedenleri var.

BASIC ile ilgili en büyük sorunlardan biri, dili ilk ortamlarının ötesine genişletmek için iyi tanımlanmış herhangi bir yöntemin olmayışıydı, bir sürü tamamen uyumsuz uygulamaya yol açtı (ve herhangi bir standardizasyonda neredeyse alakasız bir girişime).

Neredeyse herhangi bir dil, bazı çılgın programcılar tarafından genel amaçlı kullanım için eğilecektir. Çılgın bir fikrin ortaya çıkması durumunda, başlangıçta bu genel amaçlı kullanımı planlamak daha iyidir.

DSL'lere (etki alanına özgü diller) inanıyorum ve bir dilde değer verdiğim bir şey, bunun üzerine bir DSL tanımlamama izin veriyorsa olur.

Lisp'te makrolar var - çoğu insan bunu benim gibi iyi bir şey olarak görüyor.

C ve C ++ 'da makrolar var - insanlar onlardan şikayet ediyor, ancak DSL'leri tanımlamak için onları kullanabildim.

Java'da, dışarıda bırakıldılar (ve dolayısıyla C # dilinde) ve bunların eksikliği bir erdem olarak ilan edildi. Tabii bu size intellisense var sağlar, ama bana sadece bir olduğunu oeuvre . DSL'imi yapmak için, elle genişletmem gerekiyor. Bu bir acıdır ve tonlarca daha az kodla çok daha fazlasını yapmama izin vermeme rağmen kötü bir programcı gibi görünmemi sağlıyor.

İfadeler , onlara ait her dilde. İfadelerle yapamayacağınız hiçbir şey yapmazlar ve pek çok şey yapmanıza engel olurlar. ?:Üçlü bir operatörün varlığı, etraflarında dolaşmaya çalışmak zorunda olmanın sadece bir örneğidir. JavaScript’te özellikle can sıkıcı:

// With statements:
node.listen(function(arg) {
  var result;
  if (arg) {
    result = 'yes';
  } else {
    result = 'no';
  }
  return result;
})

// Without:
node.listen(function(arg) if (arg) 'yes' else 'no')

Benim için, C'den türetilen tüm dilleri rahatsız eden tasarım sorunu; yani, " başka sarkan ". Bu gramer problemi C ++ 'da çözülmüş olmalıydı, fakat Java ve C #' ya taşındı.

Bence şu ana kadarki cevapların çoğu ana dillerin başarısız olmasına işaret ediyor:

Geriye dönük uyumluluğu etkilemeden ana dili değiştirmenin yolu yoktur.

Bu çözülürse, hemen hemen bütün diğer kulplar çözülebilir.

DÜZENLE.

Bu, farklı ad alanlarına sahip kütüphanelerde çözülebilir ve bir dilin çekirdeğinin çoğu için benzer bir şey yapmayı düşünebilirsiniz, ancak bu daha sonra birden fazla derleyiciyi / tercümanı desteklemeniz gerektiği anlamına gelebilir.

Sonuçta, bunu tamamen tatmin edici bir şekilde nasıl çözeceğimi bildiğimi sanmıyorum, ancak bu bir çözümün olmadığı anlamına gelmiyor veya daha fazlası yapılamaz

Java'nın sessiz tamsayı aritmetik taşması

Hem Java hem de C #, genetik eklerken geriye dönük uyumluluğu korumak arzusundan dolayı, kendi tür sistemleri ile ilgili can sıkıcı sorunlar yaşıyor. Java, jenerik ve dizileri karıştırmayı sevmez; C #, bazı yararlı imzalara izin vermez, çünkü değer türlerini sınır olarak kullanamazsınız.

İkincisinin bir örneği olarak, bunu göz önünde bulundurun

public static T Ayrıştırma <T> (Tip <T> tipi, string str) burada T: Enum

public static object Ayrıştırma (Type type, string str)

MyEnum e = Enum.Parse (typeof (MyEnum), str);

MyEnum e = (MyEnum) Enum.Parse (typeof (MyEnum), str);

tl; dr: türünüzü tasarlamaya başladığınızda parametrik polimorfizmi düşünün, sürüm 1'i yayınladıktan sonra değil.

Alevlenmek için kendimi açıyormuş gibi hissediyorum, ancak C ++ 'da referansla eski düz veri türlerini geçme yeteneğinden gerçekten nefret ediyorum. Ben sadece referans olarak karmaşık tipleri geçemekten nefret ediyorum. Bir işleve bakıyorsam:

void foo()
{
    int a = 8;
    bar(a);
}

Çağıran noktadan, bartamamen farklı bir dosyada tanımlanabilecek olanın, şöyle olduğunu söylemenin bir yolu yoktur :

void bar(int& a)
{
    a++;
}

Bazıları böyle bir şey yapmanın sadece kötü bir yazılım tasarımı olabileceğini ve dili suçlamamak olduğunu iddia edebilir, ancak dilin bunu yapmanıza izin vermesinden hoşlanmıyorum. İşaretçi kullanma ve arama

bar(&a);

çok daha okunaklı.

alter

COBOL'ü öğrendiğimde , ALTER ifadesi hala standardın bir parçasıydı. Özet olarak, bu ifade çalışma zamanı sırasında prosedür çağrılarını değiştirmenize izin verir.

Tehlike, bu ifadeyi, nadiren erişilen bazı gizli kod bölümlerine koymanız ve programınızın geri kalanının akışını tamamen değiştirme potansiyeline sahip olmanızdı. Birden fazla ALTER ifadesiyle, programınızın herhangi bir zamanda ne yaptığını bilmeyi neredeyse imkansız hale getirebilirsiniz.

Üniversite eğitmenim, çok açık bir şekilde, bu ifadeyi programlarımızdan herhangi birinde gördüğü takdirde bizi otomatik olarak bırakacağını belirtti.

Bir programlama dilinin en kötü günahı iyi tanımlanmamıştır. Hatırladığım bir durum, kökenlerinden C ++ 'dır:

1. Kitap veya örnekleri takip ederek derlemek ve çalıştırmak için bir program elde edemediğiniz kadar hastalandı.
2. Bir derleyici ve işletim sistemi altında derleme ve çalıştırma programını değiştirdikten sonra, derleyicileri veya platformları değiştirdiyseniz baştan başlamanız gerekir.

Hatırladığım kadarıyla, C ++ 'ı C kadar profesyonel bir şekilde güvenilir hale getirecek kadar iyi tanımlanmış olması on yıl aldı . Bu bir daha asla olmaması gereken bir şey.

Günah olarak düşündüğüm başka bir şey (farklı bir cevapta mı olmalı?), Ortak bir iş yapmanın birden fazla "en iyi" yoluna sahip olmak. (Yine) C ++, Perl ve Ruby durumlarında.

C ++ 'daki sınıflar, dilde bir çeşit zorunlu tasarım kalıbıdır.

Bir yapı ile bir sınıf arasında çalışma zamanında hiçbir fark yoktur ve onu koymak istediğim "bilgi gizleme" nin gerçek gerçek programlama avantajının ne olduğunu anlamak çok kafa karıştırıcıdır.

Bunun için aşağı oylanacağım, ama yine de, C ++ derleyicileri bu dili yazmak çok zor bir canavar gibi geliyor.

Her dilin bir hatası olsa da, onları bir kez tanıdığınızda hiçbiri sıkıntı yaratmaz. Bu çift hariç:

Wordy API'lerle birleştirilmiş karmaşık sözdizimi

Bu, özellikle Objective-C gibi bir dil için geçerlidir. Sadece sözdizimi ezici bir şekilde karmaşık değildir, fakat API gibi işlev isimleri kullanır:

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath

Hepiniz açık ve belirsiz olduğum için değilim, ama bu çok saçma. Ne zaman xcode ile oturup, bir n00b gibi hissediyorum ve bu gerçekten sinir bozucu.

1. C imzalı karakterler - matematikçilerin küçük küçük koleksiyonlar yapmasına izin vermek için icat edilmiş bir istif
2. Anlamsal içerik taşımak için durum kullanma - yine konuşmaya ihtiyacı olmayan ve formülleri için hiçbir zaman yeterli alana sahip olmayan matematikçiler için
3. Letin / Plain ataması vs. Temel lehçelerde atamanın belirlenmesi - burada matematikçi olmuyor diye düşünüyorum.