Varsayılan değerler - iyi mi kötü mü?

12

Genel olarak varsayılan değerlerle ilgili soru - varsayılan döndürme işlevi değerleri, varsayılan parametre değerleri, bir şey eksik olduğunda varsayılan mantık, istisnaları işlemek için varsayılan mantık, kenar koşullarını işlemek için varsayılan mantık vb.

Uzun bir süre için varsayılan değerlerin "saf kötülük" bir şey olduğunu düşündüm, "felaketi gizleyen" ve çok zor bir hata bulmasıyla sonuçlanan bir şey. Ama son zamanlarda varsayılan değerleri bir tür teknik borç olarak düşünmeye başladım ... ki bu oldukça kötü bir şey değil, ancak "kısa vadeli finansman" sağlayabilecek bir şey bizi projeden kurtulamamıza neden oluyor (kaçımız göze alabiliyordu) ipotek almadan ev satın almak?).

"Kısa süreli" dediğimde - demek istemiyorum - "önce hızlıca bir şeyler yapın ve daha sonra üretime çarpmadan önce onu yeniden düzenleyin". Hayır - Bir üretim yazılımında sabit kodlanmış varsayılan değerlere güvenmekten bahsediyorum. Verilen - bazı sorunlara neden olabilir, ancak ya bir yıl içinde sadece tek bir soruna neden olacaksa.

Yine - burada "ortalama" ana yazılımdan bahsediyorum (nükleer güç istasyonu için bir yazılım değil) - ortalama bir web sitesi veya muhasebe yazılımı için bir UI uygulaması, yani insanların yaşamlarının tehlikede olmadığı veya milyonlarca doların olmadığı .

Yine, tecrübelerime göre, iş kullanıcıları "bir şekilde çalışıyor" yazılımı ile yaşamayı tercih ederler, daha sonra mükemmel bir tane beklerler. Ve RAD tarzında bir yazılım geliştirirseniz varsayılan değerlerin kullanımı çok yardımcı olur. Ama yine de - harcadığım en uzun hata ayıklama oturumları, yol boyunca "varsayılan" olmayı bırakan varsayılan bir değerin getirdiği hatalardan veya küçük bir alt sistemin yakın zamanda yükseltilmesinden ve bu yükseltmenin bir sonucu olarak varsayılanı doğru şekilde işleyin (örn. boş liste null veya boş dize vs boş dize).

Benim sorum şu - varsayılan değerler iyi mi kötü mü? Ve eğer teknik bir borçsa - geri ödemeleri karşılayabilmek için ne kadar ödünç alabileceğinizi nasıl ölçersiniz?

Herhangi bir girdi gerçekten takdir ediyorum.

Şerefe.

DÜZENLE:

Varsayılan değerleri geliştirme sırasında köşeleri kesmenin bir yolu olarak kullanıyorsam - ve köşeleri kesen hatalara ve sorunlara neden oluyorsa - bu sorunlardan kurtulmanın yöntemi nedir?

programming-practices

24

Yapılandırma Konvansiyonu kavramı, makul varsayılan değerler olmadan imkansızdır . Buradaki anahtar kelime "mantıklı" dır. Varsayılan değerler bir kütüphane / hizmet / çerçevenin tüm kullanımlarının en az% 80'i (daha fazla değilse) için anlamlı olmalıdır.

Genel kurallar:

Bir değer% 80 veya daha fazla kullanım için mantıklıysa, varsayılan bir değer olması gerekir
Vakaların çoğunda kullanılan değer yoksa varsayılanları kullanmayın.
Varsayılan değerler, kurulum kodundaki aptal hataları önler. Varsayılanlar çoğu durumda makulse, daha az kişi çalışma yapılandırmasını bozar.
Standart dışı yapılandırmalar, varsayılanları kullandığınızda daha görünür olur.
Kötü varsayılan daha kötü hiçbir varsayılan.

Temel olarak, varsayılan yapılandırmanın nasıl çalıştığını öğrendikten sonra, standart olmayan yapılandırmaların nasıl / ne zaman yapılacağı konusunda eğitimli kararlar verebilirsiniz.

— Berin Loritsch
kaynak

Beni "Konfigürasyon Konvansiyonu" kavramına yönlendirdiğiniz için teşekkür ederiz. Bir ismi olduğunu bilmeden kullandım. Bu kuralı açıklayabilir misiniz? "Standart dışı yapılandırmalar, varsayılanları kullandığınızda daha görünür." Lütfen.

3

@ Bir düzine çağrı Foo()ve bir çağrı varsa Foo("bar"), bu çağrı öne çıkma eğilimindedir ve bu nedenle daha görünürdür.

— Matthew Scharley

1

Doğru ve bir FTP hizmetinin çoğu kullanımı, new FtpService()alternatif bir bağlantı noktası ayarlayanı kullanırsa ( service.SetPort(12345)) öne çıkacaktır .

— Berin Loritsch

43

Örneğin, FTP protokolünü uygulayan bir kütüphaneyi ele alalım. Varsayılan olarak FTP'nin 21 numaralı bağlantı noktasında çalışması beklenir. Şimdi rasgele bir FTP sınıfının her nesnesini oluşturduğumda 21 numaralı bağlantı noktasını kullanmayı belirtmem gerekirse çok rahatsız olurdum. Farklı bir bağlantı noktasına ihtiyacım olursa belirteyim.

Aklı varsayılanları olduğunda varsayılanlar gayet iyi.

— Htbaa
kaynak

21

+1. En son ne zaman http://programmers.stackexchange.com:80/questions/?sort=newest&pagesize=50bir adres çubuğuna yazdınız ?

— Jörg W Mittag

1

Öyleyse, varsayılan değişkenin akıl sağlığı seviyesini nasıl ölçersiniz / tahmin edersiniz / vb.

5

Makul bir varsayılan değeri düşünmek ne kadar sürer.

— Alexander Gessler

1

@Andrew, cevabımı aşağıya bakın. Bir değer% 80 veya daha fazla kullanım için iyiyse, iyi bir varsayılan değerdir.

— Berin Loritsch

2

@Berin Loritsch: Varsayılan değer güvenli bir şekilde başarısız olmak için kullanılıyorsa, zamanın yalnızca% 1'i kullanıldığında bile iyi olduğunu iddia edebilirsiniz.

— oosterwal

18

Muhtemelen varsayılan tuş eşlemeleri, varsayılan fare düğmesi eşlemeleri, varsayılan tarayıcı, sistem varsayılan dilini yazarak, önyükleme yükleyicisindeki varsayılan işletim sisteminden önyükleme, varsayılan konumlandırılmış menüler, varsayılan renk düzeni, varsayılan yazı tipi ile varsayılan bir klavye düzeni kullanıyorsunuz genişlik / yükseklik / yüz / stil, varsayılan karakter kümesi, varsayılan monitör çözünürlüğü, varsayılan ... fikir olsun.

Ama ciddiyetle, yaşadığınız endişenin varsayılanlarla değil, başka bir şeyle olduğunu düşünüyorum. Varsayılan davranış hataları doğal olarak maskelemez. Çoğu zaman, varsayılanları ayarlayıp ayarlamamanıza bakılmaksızın, kodunuz yine de ortak koşullar altında çalışacaktır. İşlenmemiş kenar durumları, varsayılanlar değiştirildiğinde veya olağandışı bir senaryo gerçekleştiğinden bağımsız olarak (muhtemelen yeterli ve uygun testlerle) kaçınmak istediğinizden emin olmak isteyeceğiniz şeylerdir.

Ayrıca, "tümünü yakala" kural dışı durum işleme, "varsayılan" olarak adlandırabileceğiniz herhangi bir şeyden ziyade bir tasarım hatasıdır.

— Rei Miyasaka
kaynak

Tamam, "hepsini yakala" aslında iyi bir örnektir. Evet - bir gün bilinmeyen bir nedenden ötürü bir şeyler ters gittiğinde çok fazla kedere neden oluyor ve bu "bazıları" büyük ölçüde bilinmiyor çünkü gerçek istisna bir tümünü yakalama bloğunda kayboldu. Bu kötü bir şey - değil mi? Öte yandan - bir tümünü yakalama bloğu olmadan, yazılım tamamen ölüyor olabilir (istisna ele alınmazsa) veya karmaşık bir hata işleme mantığı gerektirir (en azından istisnayı günlüğe kaydetmek ve bazı verileri bir varsayılan değerler).

Orijinal sorumu eklemek için - geliştirme sırasında köşeleri kesmenin bir yolu olarak varsayılan değerleri kullanıyorsam - ve köşelerin kesilmesi bir hata ve sorunla sonuçlanırsa - bu sorunlardan kurtulmanın en iyi yolu nedir?

1

İstisnalar söz konusu olduğunda, iş parçacığı başına , varsa, bir tümünü yakalama istisnası olması gerektiğini söyleyen bir makale vardır . Hata raporlaması için kullanılır, bu nedenle programa, işletim sisteminin bir sürece baktığı gibi tek bir "şey" olarak bakıyorsunuzdur. Döngüde son kullanıcı (ve umarım geliştiriciler) bulunduğundan, istisnayı aslında "yutmazsınız" - bu yüzden hepsi iyi. Buradaki makale: codeproject.com/KB/architecture/exceptionbestpractices.aspx

— Rei Miyasaka

1

Hataları önlemek için varsayılanları kullanmaya gelince - + f / mac + f'yi kontrol edebileceğiniz tutarlı bir yorum kullanmaya ne dersiniz? Örneğin, Visual Studio aslında TODO: or TEMP:görevler listesinde başlayan yorumları gösterir. Eğer gelişim uğruna bir köşeyi kesersem, oraya bir TODO koyduğumdan emin olmak için son derece dikkatli olmaya çalışırım - o zaman, arada bir, geri dönüp emin olmak için bir "hepsini bul" yapacağım bunların hiçbiri önemli yapılara girmez.

— Rei Miyasaka

Hata! Geliştirmeye yardımcı olması için sabit kodlanmış değerler kullanmak istedim. Bu arada, "sabit kodlanmış değerler" in muhtemelen "varsayılan değerler" yerine aradığınız kelime olduğunu fark ettim.

— Rei Miyasaka

3

Varsayılanlar, kullanıcıyı veya geliştiriciyi tekrarlayan görevleri gerçekleştirmekten kurtardıklarında kullanılmalıdır. Hiçbir zaman hataları veya istisnaları maskelemek için kullanılmamalıdır. Hataları önlemek için bunları kullanmak kötü bir uygulama değildir, ancak önleme kötü bir şeyi maskelemediği sürece. Varsayılan değerler, her şey gibi bir araçtır. Düzgün kullanıldıklarında size çok fazla baş ağrısı ve zaman kazandırabilirler. Yanlış kullanıldıklarında bütün evi yıkabilirler.

— Joel Etherton
kaynak

C ++ gibi tüm bacağını üfleme gibi ...

— Mateen Ulhaq

1

@muntoo: Hey, Lisp bana '03'te geri döndü.

— Joel Etherton

3

Belirttiğiniz sorunların temel nedeni varsayılan değerler değil, arayüz sözleşmelerinin değiştirilmesi, yorum yanlış anlaşılmaları ve / veya geçersiz varsayımlar nedeniyle entegrasyon sorunlarıdır. Temel olarak, tüm bunlar (belirli örnekler), müşteri ile geliştirici veya farklı geliştiriciler / ekipler arasındaki uygunsuz iletişimin sonucu gibi görünmektedir . Yeterince adil, bu sorunlar olabilir geçersiz varsayılan değerler olarak değil, aynı zamanda sayısız diğer şekillerde tezahür.

Belirtiyi değil, kök nedeni ele alın.

Ayrıca, diğerlerinin mükemmel örneklerle işaret ettiği gibi, akıllıca kullanıldığında varsayılan değerlerin kullanıcıların ömrünü önemli ölçüde kolaylaştırabileceğini unutmayın. Nihayetinde amacımız bu, değil mi?

— Péter Török
kaynak

"Yanlış iletişim" temel sebep olabilir, ama hemen hemen hiçbir şeyin temel nedeni değil mi? Ve "nihai amacım" maliyet kısıtlı bir ortamda zamanında "yeterince iyi" bir yazılım sunmak olduğundan, kötü / kötü varsayılanları iyi olanlardan nasıl anlatacağımı bilmek istedim.

@Andrew, iletişim (veya eksikliği) bir projenin başarısında / başarısızlığında önemli bir faktördür, ancak tek proje olmaktan uzaktır. Ancak, suçlu olduğunda, düzgün bir şekilde ele alınmalıdır, aksi takdirde projeniz neredeyse kesinlikle mahkumdur. Kötü varsayılanları iyi olanlardan ayırmak için herhangi bir sihirli araç bilmiyorum: IMHO, problem alanının, kullanım durumlarının vb.

— Péter Török

1

İletişim protokolünün / kuralının bir parçası olmayan varsayılan değerler kötüdür. "Bir parça değil" demekle, protokolün katı olduğu yerde belgelenmedikleri veya protokolün gevşek olduğu yerlerde beklenmedikleri anlamına gelir.

Varsayılan değer belgelenir / beklenirse, yine de kötü olabilir, ancak yaşamları da güvence altına alabilir. Etki alanı alanına bağlıdır. Çok tehlikeli olabildiklerinde (örn. Varsayılan ilaç dozu, varsayılan asansör katı, varsayılan araba hareket yönü) ve bazen bunlara sahip olmamaları tehlikeli olabilir (örneğin, varsayılan araba hareket yönü, varsayılan toplantı süresi).

— astef
kaynak