Sağlam kodu ne tanımlar?


42

Profesörüm, "sağlam" koddan bahsettiği zaman bu Java örneğine atıfta bulunur:

if (var == true) {
    ...
} else if (var == false) {
    ...
} else {
    ...
}

"Sağlam kod" un, programınızın tüm olasılıkları dikkate aldığı ve bir hata diye bir şey olmadığı anlamına geldiğini iddia eder - tüm durumlar kod tarafından ele alınır ve geçerli durumda, dolayısıyla "başka" olarak sonuçlanır.

Ancak şüpheliyim. Değişken bir boolean ise, üçüncü bir durum mantıksal olarak imkansız olduğunda üçüncü bir durumu kontrol etme noktası nedir?

"Hata diye bir şeye sahip olmamak" saçma gibi görünüyor; Google uygulamaları bile, onları sessizce veya bir şekilde geçerli durum olarak düşünmek yerine yutmak yerine doğrudan kullanıcıya gösterir. Ve bu iyi - Bir şeyin ne zaman ters gittiğini bilmek hoşuma gidiyor. Ve bir uygulamanın hiçbir zaman hata yapmayacağını söylemek iddiası görünüyor.

Peki "sağlam kod" un asıl tanımı nedir?



4
Bu sadece kesin olarak yazılmış bir dilde geçerli olurdu. Güçlü bir şekilde yazılmış bir dilde, bir boolean tipi (bir boolean gibi poz veren bir tamsayı değil) değişkeni yalnızca doğru ya da yanlış olabilir, üçüncü bir seçenek yoktur ...
Marjan Venema

23
3. vakadaki kapsamı nasıl test edeceğinizi sorun, çünkü sağlam kodun mutlaka test edilmesi gerekir ve 3. davayı test edemezseniz, içinde gizlenebilecek herhangi bir hata bulamazsınız.
gbjbaanb

2
@Marjan - güçlü bir şekilde yazılmış olmayan bir dilde yazmanız en muhtemel olan: eğer (var) {} else {}
kevin cline

2
Hem x'in hem de! X'in gerçek olabileceği dilleri bilmiyorum. "İf (x == true) ..."; Bu tür karşılaştırmalardan nefret ediyorum.
kevin cline

Yanıtlar:


33

Üçüncü bir durum mantıksal olarak imkansız olduğunda üçüncü bir durumu kontrol etme noktası nedir?

Ne doğru ne de yanlış Boolean?bir NULLdevlet için izin veren bir şey var. Şimdi yazılım ne yapmalı? Bazı yazılımların kalp pilleri gibi çarpmalara karşı dayanıklı olması gerekir. Hiç biri bir veritabanına sütun Booleaneklenmiş ve şu anki verileri NULLbaşlangıçta başlatan görmüş mü? Onu gördüğümü biliyorum.

Yazılım açısından sağlam olmanın ne demek olduğunu tartışan birkaç link:

Burada "sağlam" tanımında evrensel olarak kabul edilmiş bir görüş olduğunu düşünüyorsanız, iyi şanslar. Bomba geçirmez veya salak geçirmez gibi bazı eş anlamlılar olabilir. Koli Bandı Programcısı , en azından terimleri anladığımda genellikle sağlam kod yazan bir örnek olabilir.


13
Bu bir null boolean olsaydı, hem Java hem de c # atılırdı, önce null kontrol edilmelidir.
Esben Skov Pedersen

Bir kedinin veya köpeğin ne olduğunun tanımı konusunda evrensel olarak kabul görmüş gibi görünmüyor.
Tulains Córdova

11

Benim tartışmam uğruna bir Bool'un Doğru veya Yanlış olmak üzere 2 durumu olabilir. Başka bir şey programlama dili spesifikasyonlarına uygun değildir. Eğer takım zinciriniz spesifikasyonlarına uygun değilse, ne yaparsanız yapın hortumludur. Bir geliştirici 2 durumdan fazla olan bir Bool türü oluşturduysa, kod tabanımda yapacağı en son şey bu olurdu.

Seçenek A

if (var == true) {
    ...
} else if (var == false) {
    ...
} else {
    ...
}

Seçenek b

if (var == true) {
    ...
} else {
    ...
}

Seçenek B'nin daha sağlam olduğunu iddia ediyorum .....

Herhangi bir twit beklenmedik hataları ele almanızı söyleyebilir. Onlar genellikle bir kez düşününce algılanması kolaydır. Profesörünüzün verdiği örnek, olabilecek bir şey değil, bu yüzden çok zayıf bir örnek.

Eşleştirilmiş test kablo demetleri olmadan test etmek mümkün değildir. Eğer yaramazsan, nasıl test edeceksin? Kodu sınamamışsanız, çalıştığını nasıl anlarsınız? Eğer işe yaradığını bilmiyorsanız, sağlam bir yazılım yazmıyorsunuzdur. Bence hala buna Catch22 diyorlar (Harika film, bazen izleyin).

B Seçeneği test etmek için çok önemlidir.

Bir sonraki sorun, profesörünüze şu soruyu sorun: "Bir Boole ne Doğru, ne Yanlış ise bu konuda ne yapmamı istiyorsunuz?" Bu çok ilginç bir tartışmaya yol açmalı…

Çoğu durumda, bir çekirdek dökümü uygundur, en kötüsü kullanıcıyı rahatsız eder veya çok paraya mal olur. Modül Uzay mekiği gerçek zamanlı yeniden giriş hesaplama sistemi ise ne olur? Herhangi bir cevap, ne kadar yanlış olursa olsun, kullanıcıları öldürecek şekilde iptal etmekten daha kötü olamaz. Öyleyse ne yapmalı, cevabın yanlış olduğunu biliyorsanız, 50 / 50'ye gidin veya% 100 başarısızlığı iptal edin. Mürettebat üyesi olsaydım, 50/50 alırdım.

Seçenek A beni öldürür Seçenek B bana hayatta kalma şansını bile verir.

Ama bekleyin - uzay mekiği girişinin bir simülasyonu - öyleyse ne? İptal et, bunu biliyorsun. İyi bir fikir gibi geliyor mu? - DEĞİL - çünkü göndermeyi planladığınız kodla test etmeniz gerekir.

Seçenek A, yatma için daha iyidir, ancak konuşlandırılamaz. Faydası yok Seçenek B konuşlandırılmış koddur, böylece simülasyon canlı sistemlerle aynı şekilde çalışır.

Bunun geçerli bir endişe olduğunu varsayalım. En iyi çözüm, hata işlemeyi uygulama mantığından izole etmek olacaktır.

if (var != true || var != false) {
    errorReport("Hell just froze over, var must be true or false")
}
......
if (var == true){
 .... 
} else {
 .... 
}

Daha fazla okuma - Therac-25 Xray makinesi, Ariane 5 Roket arızası ve diğerleri (Link birçok bağlantıya sahiptir, ancak Google’ın yardımcı olacağı konusunda yeterli bilgi vardır)


1
“.. beklenmedik hatalar. Genellikle bir kez düşündüğünüzde algılaması genellikle kolay olur” - ancak onları düşündüğünüzde, artık beklenmeyen bir durum değildir.
gbjbaanb

7
Kodunuzun yerine olması gerekip gerekmediğine dair bazı sorular var . if (var != true || var != false) {&&

1
Ne doğru ne de yanlış bir bool kolayca düşünebilirim, ama yine de beklenmedik. Bir boolun başka bir şey olamayacağını söylerseniz, bir harfin rakamlı bir karakter olup olmadığını kontrol edip sonra onu tamsayı değerine dönüştürürsem, o tamsayı değerinin 0'dan küçük veya 9'dan büyük olduğunu kolayca düşünebilirim, ancak yine de beklenmedik.
gnasher729

1
Boş Boolean'lar Java ve C # ile desteklenir ve gerçek dünyadan bir uygulamaya sahiptir. İnsanların listesini içeren bir veritabanı düşünün. Bir süre sonra bir cinsiyet (isMale) alanına ihtiyacınız olduğuna karar verirsiniz. Boş, "asla sorulmadığını bilme" anlamına gelir; gerçek erkek, yanlış erkek demektir. (Tamam, trans cinsiyet basitlik için ihmal edildi ...).
kiviron

@kiwiron: "Erkek", "Kadın", "Sorma" adlı bir numaralandırma türünü kullanmak daha iyi bir çözüm olmaz mıydı. Numaralandırmalar daha iyidir - ihtiyaç ortaya çıktığında uzatılabilir (örn. Asexual, Hermafrodit, "Cevap Vermeyi Reddetti" aklınıza gelsin).
mattnz

9

Aslında kodunuz daha sağlam değil, LESS sağlam. Sonuncusu else, test edemediğiniz yalnızca ölü koddur.

Uzay araçları gibi kritik yazılımlarda, ölü kod ve daha genel olarak denenmemiş kod yasaktır: Eğer kozmik bir ışın, sıra dışı kodunuzu aktif hale getirecek şekilde bozan tek bir olay meydana getirirse, her şey mümkündür. SEU sağlam kodun bir bölümünü etkinleştirirse, (beklenmeyen) davranış kontrol altında kalır.


Uzay gemilerinde anlamıyorum ölü kod yasak mı? yani diğerini yazamaz mısın? Test edemediğin için koyamadın mı? ama o zaman ne demek "SEU sağlam kodun bir bölümünü aktive ederse, (beklenmeyen) davranış kontrol altında kalır."
perişan

5
Evet, uzayda kritik yazılım test kapsamı% 100 olmalı ve sonuç olarak erişilemeyen kod (aka ölü kod) yasaktır.
mouviciel

7

Profesörün "hata" ve "hata" ile kafa karıştırıcı olabileceğini düşünüyorum. Sağlam kod kesinlikle çok az / hiç hata içermemelidir. Sağlam kod, düşmanca bir ortamda iyi bir hata yönetimine sahip olmalıdır (istisna işleme veya sıkı iade durumu testleri hariç).

Profesörün kod örneğinin saçma olduğu, benimki kadar saçma olmadığı konusunda hemfikirim.

// Assign 3 to x
var x = 3;
x = 3;   // again, just for sure
while (x < 3 or x > 3) { x = 3; }  // being robust
if (x != 3) { ... }  // this got to be an error!

1
Sonunda kesinlikle tetiklenirse, gerçekten bu kadar çaba gerektirmez. Herhangi bir deneyimli C programcısı aniden değişmiş değerleri görmüştür. Tabii ki, mantıksal olarak, kontrollü tek dişli bir ortamda, bu asla olmamalı. Gerçek hayatta, eğer içindeki kod sonunda olacak. Yararlı bir şey yoksa, içinde yapabilirsin, sonra kodlama! (Belirli bir yazılım geliştirme sırasında, imkansız bir şey olması durumunda, küfür sözleriyle bir istisna oluşturduğum komik bir deneyim yaşadım ... tahmin et ne oldu?).
Alex

2
Gerçek hikaye:boolean x = something(); if (x) { x = True // make sure it's really true, ... }
Andres F.

6

Robust Code'un tanımlanması konusunda bir fikir birliği yoktur , çünkü programlamadaki birçok şey için bu aşağı yukarı özneldir.

Profesörünüzün verdiği örnek dile bağlıdır:

  • Haskell'de a Booleanolabilir Trueveya Falseüçüncü bir seçenek yoktur.
  • C ++ ile bir boololabilir true, falseya da (maalesef) bilinmeyen bir kutusuna koyun bazı şüpheli döküm gelen ... Bu gerektiğini olur, ama olmayabilir, bir önceki hata sonucu.

Bununla birlikte, profesörünüzün önerdiği şey , ana programın ortasında gerçekleşmemesi gereken olaylar için yabancı olmayan bir mantık sunarak kodu gizler , bu yüzden sizi Savunma Programlamasına yönlendiririm .

Üniversite örneğinde, Sözleşmeye Göre Tasarım stratejisini benimseyerek bunu da artırabilirsiniz:

  • Sınıflar için değişmezler oluşturun (örneğin, listedeki sizeöğelerin sayısıdır data)
  • Her bir işlev için ön koşullar ve son koşullar belirleyin (örneğin, bu işlev yalnızca en aaz olmasıyla çağrılabilir 10)
  • Her birinin işlevlerinin giriş ve çıkış noktalarında test edin.

Örnek:

class List:
  def __init__(self, items):
    self.__size = len(items)
    self.__data = items

  def __invariant(self):
    assert self.__size == len(self.__data)

  def size(self):
    self.__invariant()

    return self.__size

  def at(self, index):
    """index should be in [0,size)"""
    self.__invariant()
    assert index >= 0 and index < self.__size

    return self.__data[index]

  def pushback(self, item):
    """the subsequent list is one item longer
       the item can be retrieved by self.at(self.size()-1)"""
    self.__invariant()

    self.__data.append(item)
    self.__size += 1

    self.__invariant()
    assert self.at(self.size()-1) == item

Ancak profesör özellikle Java olduğunu söyledi ve özellikle de türün ne olduğunu söylemedi. Boolean ise, doğru, yanlış veya boş olabilir. Başka bir şey varsa, hem doğru hem de yanlış için eşit olmayabilir. Evet, sağlam, savunma ve paranoyak arasında örtüşme.
Andy Canfield

2
C, C ++ ve Objective-C'de, bir bool diğer türlerde olduğu gibi belirsiz bir değere sahip olabilir, ancak herhangi bir atama onu doğru veya yanlış olarak ayarlayacaktır. Örneğin: bool b = 0; b ++; b ++; b'yi true olarak ayarlayacaktır.
gnasher729

2

Profesörünüzün yaklaşımı tamamen yanlış yönlendirilmiş.

Bir işlev veya yalnızca bir parça kod, ne yapabileceğini söyleyen ve mümkün olan her girişi kapsayan bir özelliğe sahip olmalıdır. Ve kod, davranışının spesifikasyonla eşleşmesini garanti altına almak için yazılmalıdır. Örnekte, spesifikliği şöyle basit basardım:

Spec: If var is false then the function does "this", otherwise it does "that". 

Sonra işlevi yazınız:

if (var == false) dothis; else dothat; 

ve kod spec karşılar. Yani profesörünüz diyor ki: Ya var == 42? Spesifikasyona bakın: Fonksiyonun "bunu" yapması gerektiğini söylüyor. Koduna bakın: İşlev "o" yapar. Fonksiyon spec karşılar.

Profesörünüzün kodunun işleri tamamen rahatsız edici hale getirdiği nokta, yaklaşımı ile var'in ne doğru ne de yanlış olduğu zaman, daha önce hiç çağrılmayan ve tamamen denenmemiş, tamamen tahmin edilemeyen sonuçlarla kodunu çalıştıracağı gerçeğidir.


1

@ Gnasher729'un ifadesine katılıyorum: Profesörünüzün yaklaşımı tamamen yanlış yönlendirilmiş.

Sağlam, kırılmaya / arızaya karşı dirençli olduğu anlamına gelir; çünkü çok az varsayımda bulunur ve ayrıştırılır: kendi kendine yeten, kendini tanımlayan ve taşınabilir. Ayrıca değişen gereksinimlere uyarlanabilir olmayı da içerir. Bir kelimeyle, kodunuz dayanıklıdır .

Bu, genel olarak, verilerini arayan tarafından iletilen parametrelerden alan kısa işlevlere ve tüketiciler için ortak arabirimlerin kullanımına - soyut yöntemler, sarıcılar, dolaylı, COM tarzı arabirimler, vb. - somut uygulama kodu içeren işlevler anlamına gelir.


0

Sağlam kod basitçe arızaları iyi idare eden koddur. Ne fazla ne az.

Başarısızlıkların birçok türü vardır: yanlış kod, eksik kod, beklenmeyen değerler, beklenmeyen durumlar, istisnalar, kaynak tükenmesi, .... Sağlam kod bunları iyi idare eder.


0

Verdiğiniz kodu, savunma programlamaya bir örnek olarak kabul ediyorum (en azından bu terimi kullandığım gibi). Savunma programlamasının bir kısmı, sistemin geri kalanı hakkında yapılan varsayımları asgariye indiren seçimler yapmaktır. Örneğin, bunlardan hangisi daha iyi:

for (int i = 0; i != sequence.length(); ++i) {
    // do something with sequence[i]
}

Veya:

for (int i = 0; i < sequence.length(); ++i) {
    // do something with sequence[i]
}

(Farkı görmekte sorun yaşıyorsanız, döngü testini kontrol edin: ilk kullanım !=, ikinci kullanım <).

Şimdi, çoğu durumda, iki döngü tam olarak aynı şekilde davranacaktır. Ancak, birincisi (karşılaştırmakla birlikte !=), iher yineleme için sadece bir kez artırılacak bir varsayım yapar . Değeri atlarsa, sequence.length()döngü dizinin sınırlarının ötesine devam edebilir ve bir hataya neden olabilir.

Bu nedenle, ikinci uygulamanın daha sağlam olduğuna dair bir iddiada bulunabilirsiniz: bu, döngü gövdesinin değişip değişmediğine dair varsayımlara bağlı değildir i(not: aslında hala ihiçbir zaman olumsuz olmayan varsayımı yapar ).

Neden bu varsayımı yapmak istemeyeceğinize dair bir motivasyon vermek için, döngünün bir dize taradığını, bazı metin işlemlerini yaptığını hayal edin. Siz döngüyü yazın ve her şey yolunda. Artık gereksinimleriniz değişiyor ve metin dizisindeki kaçış karakterlerini desteklemeniz gerektiğine karar veriyorsunuz, böylece döngü gövdesini değiştirirsiniz, böylece bir kaçış karakteri algılarsa (ters eğik çizgi), ikaçıştan hemen sonra karakteri atlamak için artar . Şimdi ilk döngü bir hata içeriyor çünkü metnin son karakteri ters eğik çizgi ise, döngü gövdesi artar ive döngü dizinin sonunun ötesinde devam eder.


-1

Bir kodu şahsen bu önemli özelliklere sahip 'sağlam' olarak tanımlarım:

  1. Annem önünde oturur ve onunla çalışırsa, sistemi kıramaz

Şimdi, mola vermek gerekirse ya sistemi dengesiz bir duruma sokmak ya da UNHANDLED istisnalarına neden olmak demek . Bilirsiniz, bazen basit bir konsept için, karmaşık bir tanım ve açıklama yapabilirsiniz. Fakat basit tanımları tercih ederim. Kullanıcılar sağlam uygulamalar bulmakta oldukça başarılılar. Uygulamanızın kullanıcısı size hatalar, durum kaybı, sezgisel olmayan iş akışları vb. Hakkında birçok istek gönderirse, programlamanızda yanlış bir şey vardır.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.