super. ja ako IT laik mam taketo clanky velmi rad. vdaka :). snad pribudnu dalsie.

Že žádného takového odborníka neznám. Většina odborníků se naopak přiklání k tomu, aby program běžel dál, dokud to jde aby mohl pracovat bez chyby a naopak se zavádí pokročilé techniky logování, například dříve nedostupný výpis call stacku při výjimce, odesílání SMS při nestandardním stavu atd. atd. Zrovna u SMTP serveru je jeden neodeslaný email menší zlo, než půl denní odstávka než se probudí administrátor a udělá restart.

Mě se tento článek zdá naopak dost “mimo mísu”. Autor nějak zapomněl zmínit, že naprostá většina chyb v programu vzniká chybným vstupem od uživatele. Robustnost poté spočívá především v ošetření těchto chybných vstupů (nikoli v nějakém zatajování dělení nulou).

3: Pokud děláš aplikační programy tak dost možná. Ale pokud hledáš kolize hashů, čachruješ s XML, zpracováváš obrázky apod. tak vstup od uživatele je to nejmenší.

#3: Nezmiňuje to tam, ale reakce na to je úplně stejná. Nedostatečně oštříme vstup a do systému se dostanou nesmyslná data. Při výpočtu z nich má program udělat co? Přeskočit je? Zkoušet je převést na vypočitatelné (převod znaku na číslo, vědomě či nevědomě)? Zastavit se a vykřiknout: Nic nebudu dělat, jelikož nemohu počítat s tímto (a výpis).

Tento článek nebyl o tom, jak chyby vznikají, či jak se jim vyvarovat… ale o tom, jak na ně reagovat, pokud už se vyskytnou.

(ale uznávám, že příklad s dělení nulou při hodu banánem není nejlepší… mě napadlo vykreslení obrázku, který je porušený… Dokreslit i když špatně, nebo zrušit kreslení…)

Když už si chci hrát na odborníka a vysvětlovat nějaké pojmy, tak to aspoň udělám pořádně. Robustnost je vysvětlená dost pochybně a korektnost je matematický termín, nejčastěji používaný v predikátových logikách a do programování bych ho moc netahal a když už tak v žádném případě ne v tom smyslu v jakém ho zde prezentoval autor.

[2]
Pises to sice hezky, ale o necem jinem. Samozrejme, ze pokud mozno, mel by program pracovat bez chyby. Tento princip ale nastupuje v momente, kdy se nejaka chyba stane (a zabranit tomu nelze). Nejak se k ni program postavit musi. Zalogovani neni zadne postaveni se chybe, to je jen zaevidovani chyby, ale po nem musi program neco udelat - ukoncit se nebo pokracovat ? Na co se snazim poukazat, je, ze pokracovat po chybe neni vzdy vyhodne - mozna ze v pripade SMTP ano, ale o nem rec prece neni, ze ?

[3] je uplne jedno, jak chyby vznikaji - to byl jen vedlejsi odstavec pro bezneho ctenare, aby ho clanek uvedl do vysvetlovani principu
ale at uz chyba vznikne jakkoliv, je potreba se k ni nejak postavit - a o tom je clanek

[5]
nojo, ale podstata neni ta, jestli vykreslit spatne nebo nevykreslit (to mas pravdu, ze by byla uvaha o robustnosti ci korektnosti toho jednoho snimku); hlavni pointa je ale ta, zda dale po onom (ne)vykresleni v programu vubec pokracovat, protoze chyba mohla zmenit vnitrni stav programu a program se nadale muze chovat nedefinovane
jinak gratuluju, jsi prvni diskutujici, ktery pochopil, o cem clanek je

[6] Steven McConnell ve sve knize Code Complete robustnost i korektnost vysvetluje velmi podobne (take velmi prikladove a bez presne definice)a korektnosti urcite nemysli zadny matematicky termin. A pritom to nebrani tomu, aby se ona kniha stala bibli programatoru.
Velmi doporucuji si knihu nastudovat a teprve potom psat “moudra” po diskuzich.

[1] Ano, jsi jeden z typickych ctenaru, kteremu jsou tyto clanky urceny; dekuji za zpetnou vazbu, precti si celou rubriku Principy programovani. Samozrejme do ni budu postupne dale pridavat dalsi clanky.

Ja bych teda korektnost videl trochu jinak. Korektni program je takovy, ktery presne odpovida specifikacim(pozadavkum) a pokud se stane nejaka chyba, ktera neni zapricinena programem(treba chybny vstup), tak s tim muze program nalozit jak uzna za vhodne(treba spadnout, nebo pokracovat) a nijak to na korektnosti neubira. Pokud se snazi pokracovat, tak ho muzeme nazvat robustnim, ale stale bude korektni. Rozhodne bych nehovoril o protipolech, protoze oba pojmy jsou neporovnatelne.

No, mnou produkovaný kód (v čemkoli) je vždycky robustní ;-). Avšak při nějakém zásadním problému alespoň uživateli dovolím práci uložit/dokončit - teda pokud není onen problém v ukládání.

[12]
nemas vubec pravdu, respektive urcite ne ve vztahu k osetreni chyb (neni rec o korektnosti programu, ale o korektnosti jako zpusobu reakce na chybu!)
cituji z Code Complete, 2nd edition, kapitola 8.3 “Error Handling Techniques”, strana 12:
“Correctness means never returning an inaccurate result; no result is better than an inaccurate result. Robustness means always trying to do something that will allow the software to keep operating, even if that leads to results that are inaccurate sometimes.”
Ze si korektnosti pojmenovavas neco uplne jineho, je sice hezke, ale prave od toho tu muj clanek je, aby vam ukazal nezname principy. Zrovna tady vidis, ze tyto clanky mohou byt cas od casu prinosem i jinak znalym programatorum - coz jsem koneckoncu velmi rad. Co znamena korektnost a co robustnost, nebylo jasne ani nasemu ARCHITEKTOVI !
Jen tak mimochodem, citace o radek vys - k tomu, jak jsi psal, ze ti vubec nepripada, ze tyto dva terminy jsou protiklady: “Developers tend to use these terms informally, but, strictly speaking, these terms are at opposite ends of the scale from each other.”

A kdyz uz jste me donutili tuto knihu otevrit, ocituji pro Martina [2] a jeho komentar, ze zadneho odbornika uprednostnujiciho korektnost nezna: “Safety critical applications tend to favor correctness to robustness. It is better to return no result than to return a wrong result.”

Jen doufam, ze jeste nezpochybnite, ze McConnell je odbornik na slovo vzaty a jeho Code Complete je jedna z fundamentalnich knih programovani.

[13] to jo, protoze programujes bezne aplikace
pokud ale budes psat program, ktery ridi dychani pro pacienta umele intubovaneho, budes riskovat, ze kvuli chybe se frekvence zdvojnasobi a tvuj program ho zabije ?

[14] Pri tomhle vykladu je ale robustnost/korektnost ciste zalezitosti striktniho dodrzovani specifikaci. Aby mohl byt dle techto definic program korektni, tak bude muset specifikace pokryvat prakticky kazdy radek vysledneho kodu, protoze jinak by se program nikam nedobral. Typycky priklad ze specifikace: “zde se zobrazi seznam polozek”. Co kdyz ale bude seznam prazdny? V tom pripade by se nemelo zobrazit nic. Jenze to je(ciste logicky vzato) v rozporu s neuplnou specifikaci. Co ted? Udelat robustni kod, ktery se nedrzi specifikace? Zmenit specifikaci? Kdyz udelame to druhe, tak jsme ziskali robustni kod(vzhledem k moznosti prazdneho seznamu), ktery je zaroven korektni, protoze se chova dle specifikace.
[15] Obavam se, ze prave ten program ridici dychani pacienta musi byt robustni. Porad lepsi, kdyz to zvysi frekvenci dychani, nez kdyz to napise “error, division by zero”

[10] Ona ta matematika s tím programováním dost souvisí. Zkuste si nastudovat něco o teoretické informatice a pochopíte, že termín korektnost je trošku o něčem jiném. A to je teorie prověřená desetiletími, takže bych v tom nedělal guláš. Nějaký pan McConnell (ač si o něm nemyslím nic špatného) je vcelku irelevantní, stejně jako to jak si nazval něco ve své knize.

[16[14]]
no dobre, ale pokud tomu rozumim, nyni se uz bavime o tom, zda by urceni, kdy je spravne pozadovane chovani robustnost nebo korektnost, melo byt soucasti specifikace nebo ne; coz je vyrazny posun proti tomu, co jsi psal predtim, kdy ses dohadoval vubec o vyznamy tech terminu

zpravidla logika reakce na chyby ve specifikaci uvedena nebyva (jako napriklad v onom uvedenem pripade prazdne mnoziny polozek), protoze by pak specifikace nabyvala velkych rozmeru; v takovem pripade je bezne na zralem uvazeni programatora a zvazeni vyznamu funkce, ktera chybu zachyti, zda je spravne chovani na chybu robustnost nebo korektnost (samozrejme by ale mel obecne ctit principy zminene v clanku)
s tim, ze ve vyhranenych pripadech se samozrejme vzdy lze poradit s klientem, co by on preferoval - nekdy take robustni i korektni chovani vyjde “nastejno”
zda lze takovou specifikaci nazvat neuplnou, je trosku problematicke, protoze pak muzes rict, ze jedinou uplnou specifikaci je uz jen samotny kod; ve specifikaci imho nejde o vycisleni kazdeho prdu, ale podstatnych vlastnosti
pouze pokud by bylo ve specifikaci vylozene receno, ze v pripade chyby napriklad pokracovat v programu a chybu zaprotokolovat, pak si muzeme povidat o dodrzovani specifikace, ale tak to vetsinou nebyva
kazdopadne z hlediska clanku znamena (dokonale) korektni program takovy, ktery kazdou chybu manifestuje a ve sve cinnosti nepokracuje, zatimco (dokonale) robustni program je takovy, ktery naopak chybu nikdy nemanifestuje a nikdy nespadne; zadny program samozrejme neni dokonale robustni ani korektni, ale neco mezi na jednu ci druhou stranu

ad [16[15]] v tom se neshodneme; robustni musi byt az vyssi logika (tak, jak jsem psal v clanku, ze nizsi vrstvy by mely byt pokud mozno korektni), v tomto pripade by to vypadalo tak, ze logika, ktera ridi dychani, zaznamena chybu a zrusi cely spusteny program/modul - aby se nemohlo stat, ze se tato logika dostane do “nestabilniho” stavu; pote, co je tato logika ukoncena (korektne), nastoupi vyssi logika (at je ji cokoliv, napr. vyssi vrstva v programu samotnem nebo treba uroven operacniho systemu), ktera uz se bude chovat robustne a ukoncenou nizsi vrstvu znovu spusti od zacatku (tim je zaruceno, ze nizsi vrstva je od pocatku opet v normalnim stavu)
tady jsme si mozna nerozumeli, nemel jsem na mysli, aby system jako celek se choval vyhradne korektne (je jasne, ze nemuzes nechat pacienta nedychat), ale ze korektne se musi chovat vsechny takove casti, ktere obsahuji kriticke funkce; s tim, ze se podle vyhozene chyby vyssi vrstva zachova klidne robustne; nelze ale tolerovat, aby se funkce pocitajici dechy dostala do nedefinovaneho stavu

zadny system nemas ryze korektni nebo ryze robustni, nejde jen o to, jak se chova program jako celek, ale jak se chovaji jednotlive moduly, funkce, objekty, vrstvy apod. - viz clanek

[17]
no mne z toho celeho tveho povidani vychazi od pocatku jen to, ze termin korektnost nema jediny vyznam
Code Complete je kniha Steva McConnella, jen pro upresneni - tim ve sve knize jsem prirozene myslel Steve McConnell v jeho knize Code Complete
nevim ale, proc bych nemohl pouzivat termin korektnost v kontextu reakce na chybove stavy - tento vyznam toto slovo ma take, je mi lito; a cely clanek je o reakci na chybove stavy, tak ja nevim, asi mi neco unika, ale porad nechapu, proc bych mel brat v uvahu nejaky vyznam slova korektnost v teorii informaci, i kdyby byl provereny celou vecnosti - podle me proste mluvime jeden o koze a druhy o voze

neviem, ci sa k tomu vyjadri nejaky programator, ale moje tusenie je take, ze ak sa pri vyvoji pride na to, ze kod obsahuje nejaku chybu, ktora za istych okolnosti sposobi nekorektne spravanie alebo padnutie aplikacie, tak programator zvoli robustne riesenie a klient sa ani nedozvie, ze v kode je chyba. Jednoducho, ak chyba nie je kriticka, tak programator casto zvoli riesenie, ktore aplikacii umozni pokracovat dalej namiesto toho, aby vyladil samotny kod a pricinu problemu.

O terminologií bych zde nevedl takovou při, osobně je mi jedno jaký je význam termínu “korektnost” v matematice, zde autor popisuje teorii ošetření chybového stavu aplikace z hlediska naprogramování. Matematika má v programování nepochybně svojí roli, ale zde se bavíma jako programátoři, a stojím při autorovi.

Řekl bych, že někteří diskutující (potažmo čtenáři) vůbec nepochopili, že korektní nebo robustní chování je třeba zvažovat na základě jednotlivých funkcí a vsrstev, a že pokud se nejedná o nějakou miniaplikaci o jedné funkci, nebude program posuzován celkově jako robustní nebo korektní (z hlediska ošetření chyb). Pochopitelně je zájmem každého programátora udržet aplikaci v chodu i přes výskyt chyby, ale je především v jeho zájmu s chybou správně naložit a rozhodnout zda je možné jí řešit na úrovni dané vstvy, nebo zalogovat (a v krajním případě dočasně ignorovat) a upozornit na ní admina, nebo zda je tak kritická aby chod aplikace ukončila.

Nakonec bych uvedl, že specifikace bývá často typu “chceme to používat k tomu a k tomu, ale nemáme páru jak by to mělo vypadat nebo se to mělo chovat” a je pak na architektovi systému, a potažmo programátorovi, aby nabídl vhodná řešení při chybovém chování.

Pro mě perfektní článek, autorovi děkuji a budu se těšit na další díly.

[20]
jak bylo uvedeno v clanku hned v prvnim odstavci, nejde zde o chyby v kodu, ale o chyby pri behu programu (runtime chyby); ty vznikaji i pri jinak spravnem kodu chybnym prostredim (hardware, operacni system, uzivatel,…), ve kterem je program spusten
jiste, u beznych aplikaci bude program jako celek tihnout spis k robustnosti, protoze si to muze dovolit; ale aby se klient ani nedozvedel, ze je po nejake chybe rentgenovy pristroj stale zapnuty a “sviti”, to by byla trestuhodna chyba

[21]
gratuluji, jsi vedle [5] druhy, ktery beze zbytku pochopil, o cem clanek je a take dekuji za feedback

—————————-
pro vsechny bych rad dodal, ze clanky jsou urceny k “videni principu” - k tomu, co dela rozdil mezi “lepicem kodu” a “dobrym programatorem”; nektere principy jsou profesionalum dobre zname (generalizace a specializace), jine mene (robustnost a korektnost)
proto bych prosil kazdeho diskutujiciho, aby se nejprve snazil pochopit princip a nad clankem se zamyslel; naprosta vetsina prispevku totiz obsahuje kritiku jaksi “mimo misu” namisto k veci - je velmi patrne, jak vetsina diskutujicich ten princip “nevidi”

Jedneho dna, premyslajuc ako predat svoj program, dostal jeden programator napad. Osetril v programe kazdu moznu vynimku, cize narval try-catch-finally kam to len jeho programovaci jazyk dovolil, a nazval to robustnostou. Aby sa zakaznik blbo nepytal “a co to vlastne ta robustnost je”, rovno pridal vysvetlenie, ze to znamena, ze jeho program ma osetrenu kazdu vynimku a preto “nepada” tak casto, ako programy konkurencie… A zrodilo sa buzzword “robustnost”. Cisty marketingovy zvast, pretoze nic, ani robustnost nie je ziadna samospasitelna technika. Iny programator rovnako vymyslel pojem “korektnost”. To je cele… Z programatorskeho hladiska totiz neexistuje nic take ako robustnost, ci korektnost. Existuje len sposob akym sa programator postavi k osetreniu vynimiek. A od sposobu ako sa k nim postavi, bude program kvalitny, alebo nie. Koniec diskusie… Inak su robustnost a korektnost len a len dva klasicke marketingove zvasty, ktore sa dalsi blbec pokusil vclenit do programovacich technik. A dalsi blbci sa potom na fore zive.sk pokusali tvarit, ze vedia o co ide a mali k tomu muuudre a prevelice hodnotne pripomienky…

Nediskutujte o blbinach. Neprogramujte “robustne”, ani “korektne”. Programujte s rozumom, osetrujte vstupy, osetrujte vynimky, logujte, testujte. Hlavne proste pouzivajte rozum a kaslite na marketingove sracky a hry so slovickami. Shalom.

[23]
no dobre, na druhou stranu tento clanek je o principech; to, ze se shodou okolnosti jmenuje neco robustnost a korektnost, je z pohledu clanku vlastne nepodstatne, i kdyby se to jmenovalo jinak nebo nijak, na principu to nic nemeni
clanky pisu proto, aby ty principy zacinajici (ale v tomto pripade koukam ze i pokrocili) programatori vubec videli - kez by kazdy umel programovat s vyzralym rozumem po letite praxi, tak to ale bohuzel neni, proto se snazim kousek toho “rozumu” ukazat..
bohuzel i na zive.cz vychazeji clanky lepice kodu - ktery dokonce obcas ten kod ani slepit neumi; proto myslim, ze ukazovani, jak programatorsky “premyslet” neni od veci

To je v poriadku. Tvoj clanok ma hlavu i patu. V principe si totiz pisal o tom, ze sa nema kaslat na vynimky. Je totiz beznou praxou zacinajucich programatorov, ze vobec, alebo aspon takmer vobec neodchytavaju vynimky. Len … jednu vec si uvedom. Nie su to ziadne protipoly. Ak totiz osetrim kazdu jednu vynimku, ak budem mat takmer kazdy riadok kodu uzavrety v try-catch-finally, ale zaroven tie vynimky osetrim tak, ze vzdy ukoncia program, akurat, ze s mojou chybovou hlaskou, a nie defaultnou, dosiahol som vlastne, ze moj program je jednak “robustny”, jednak “korektny”. A uzivatel Ti na to povie vies co? Ze “To je sice cele fasa, ze program nepada, ale sa vzdy korektne sam ukonci s detailnou chybovou hlaskou, ale povedz mi preco sa nepokusil navrhnut mi riesenie, miesto ukoncenia sa? Preco som prisiel o rozrobenu robotu kvoli zbytocnej chybovej hlaske?” A to je to, co mam na mysli. Neexistuje nic take ako robustnost, nic take ako korektnost. Programy su totiz pre uzivatelov, nie programatorov. Preto musis programovat z uzivatelskeho hladiska, nie programatorskeho. A to je uplne iny pohlad na vec. Pre uzivatela bude program robustny vtedy, ked nepadne nikdy, alebo padne naozaj len obcas. A na to Ti staci osetrit mozno len 10 percent vynimiek. A korektny pre neho bude vtedy, ked sa bude dany program vediet spamatat z neocakavaneho ukoncenia. Napriklad tak, ze si priebezne ukladal rozrobenu fakturu a po restarte mi program oznami nieco na sposob “Program bol pri predoslom spusteni neocakavane ukonceny a pokusi sa pokracovat tam, kde naposledy skoncil.” a pokusi sa otvorit posledne rozrobenu fakturu aj s priebezne vlozenymi hodnotami. TO je z uzivatelskeho hladiska korektny program. A teraz si uvedom, ze aj to, ci bude “robustny”, aj to ci bude “korektny” zalezi len a len na jedinej veci - AKYM SPOSOBOM PROGRAMATOR OSETRIL VYNIMKY… A tym smerom si mal koncipovat clanok. Pokojne chod proti prudu a povedz na plnu hubu “Kaslite na marketingove recicky, kaslite na to, co kto ako nazyva. Venujte proste pozornost vynimkam, osetrite ich inteligentne a mate vyhrane.” Mozno som extremista, ale mna naozaj dost stve, ako sa ludia kazdej blbine pokusaju dat nejaky nazov. Vysledkom je neskutocny gulas v pojmoch. Az mam pocit, ze svetu vladne trend zamlzovat, komplikovat, proste robit vsetko pre to, aby nikto nerozumel tomu, co kto robi! Kazdy sa snazi robit z programovania ciernu magiu vymyslanim roznych pseudopojmov, aby vyzeral prudko IN, prudko profesionalne. A vysledok? Momentalne sa venujem viac programovaniu web stranok ako desktpovyum aplikaciam. A pozri sa na statistiku w3c konzorcia. Ich odhadom az !!!99%!!! stranok nedodrzuje standarty! Ale vsetci maju plnu hubu reci aky su tazki odbornici, ako praave oni robia stranky profesionalne… A ver mi, ze keby sa niekto pozrel na to, ako su robene desktopove programy, keby existovala nejaka ucinna metodika posudzovania ich kvality, ver mi, ze situacia by nebola lepsia. A to je viac ako len smutne… Preto … napis radsej clanok o tom, co je pri programovani naozaj potrebne. Ze vstupy treba mat plne osetrenie proti pokusom zhodit program skrz pretecenie zasobnikov a podobne trapne pokusy, poliam treba venovat zvysenu pozornost, lebo zapis do nealokovanych oblasti je jedna z najcastejsich chyb a zaroven pricin divneho chovania programu, ze try-catch-finally je uzasny nastroj pomocou ktoreho mozete dat programu priam dusu, umelu inteligenciu, nastroj pomocou ktoreho sa moze sam program rozhodnut, ci bude pokracovat a chybu len zaloguje, alebo ak je to vaznejsia chyba, priamo na nu upozorni uzivatela, ci dokonca programatora. Alebo aspon moze dat uzivatelovi moznost rozhodnut sa, ci chce pokracovat alebo nie. A hlavne ich treba ucit ze musia pisat testovacie funkcie AKO PRVE! Testovat pred, testovat pocas, testovat po! To je cesta k tvorbe dobrych programov. A na to staci len par zakladnych pouciek a dalej uz len MYSLIET. Premyslat nad tym, co prave robite, a nie ucit sa nejake pseudotechniky…

PS: Avsak pozor, toto je len zaciatok. Pre mensie projekty. Pri vacsich projektoch sa uz nezaobide nikto bez UML diagramov a nastrojov pre kolektivnu spolupracu. Preto … co keby sme spolu dali dohromady clanok o tom, co vsetko vlastne musi programator vediet. Ze to nie je len o danom programovacom jazyku, ale aj o tom, co je to SVN, UML a pod… Shalom.

[26]
no, s tim osetrovanim vyjimek tedy moc nesouhlasim; presneji receno nesouhlasim s tim, ze osetrit vyjimku v catchi znamena robustni pristup a nechat ji unhandled znamena korektnost
program je z hlediska reakce na chybu korektni tehdy, kdyz ji manifestuje a neriskuje, ze bude v nejakem nedeterministickem stavu; pritom ji klidne muze chytit v catchi, zalogovat a zacit nejakou ukoncovaci sekvenci, cleanup apod., urcite to neznamena, ze se ma zbourat se systemovym exception boxem; korektni znamena, ze je vuci uzivatelovi korektni - kdyz jsi reditel a sekretarka ti udela chybu, je korektni ji priznat, i kdyz ji pak spolu treba napravite nebo i kdyby znamenala nejaky tragicky stav; robustni znamena vlastne, ze ti ji neprizna a bude to nejak “solichat” s tim, ze to snad dobre dopadne… reakce na chybu v programu je podle toho sameho principu.. oba pristupy mohou znamenat pouziti try-catch-finally, rozdil je jen ten, CO v tom catchi udelat podle vzoru: jsem korektni a stala se chyba ? -> ukoncim svou cinnost a nahlasim rediteli, at se rozhodne dal; jsem robustni? -> nic nenahlasim a budu si to solichat sam
a to protipoly dozajista jsou

no, kazdopadne moje clanky jsou opravdu zhruba to, jak je chapes; jsou nadjazykove, protoze syntaxi se nauci cvicena opice, ale myslet uz ne

urcite se nebranim vytvorit i spolecny clanek, ale se zachovanim ducha principu programovani - nadjazykovost a take bez konkretnich technik
clanek, co vsechno musi programator znat, je prilis obsahle tema, tyto clanky jsou o principech, ktere by mel znat a ctit, vedle toho bys samozrejme mohl psat o jednotlivych jazycich, source safech apod..
co se tyka SVN (a vubec CVS-derived systemu), to je zrovna ukazka specialni dovednosti - clanky maji za cil ukazovat principy mysleni, ne source safe technologie
totez UML.. UML je jen konvence znazorneni (i kdyz primo delana pro programovani a objektovy pristup), ale neni to zpusob mysleni pri necem

co z tvych navrhu me ale inspirovalo pro clanek, byl onen zmineny test-driven pristup, to uz je jeden princip, jak ke konkretnimu programovani pristupovat a s tvym svolenim bych o nem napsal jeden z clanku - zatim mam ale beztak temat dost

taktez se nebranim dat spolu dohromady clanek, ozvi se mi na richard.matyas (at) rm-software.cz pripadne s navrhem nektereho principu, ktery se pri programovani uplatnuje, a urcite ho sem muzeme spolu zkusit placnout

Urcite ten clanok spolu zbuchame, behom par dni sa ozvem. Len som momentalne zaneprazdneny.

Nechci se s autorem nejak velice prit, ale pojmy robustnost a korektnost chapu asi odlisne.

Tedy program je korektni, prave kdyz je kazdemu vstupu poskytuje spravny vystup. (Cili kdyz funkce na vypocet faktorialu vraci pri vstupu 5 125, neni korektni, protoze ocekavany vystup je 120).

Za robustni prohlasim program tehdy, jestlize je schopny reagovat na neocekavany vstup (do funkce pro vypocet faktorialu poslu jako parametr znak).

[29]
no, ono v podstate nejde o to, co kterymi pojmy chapes Ty - bez urazky samozrejme
jiste se shodneme, ze takova kapacita jako Steve McConnell toto nebude psat do vetru
jak uz jsem v diskuzi psat nescetnekrat, korektnost i robustnost jsou dva protikladne pristupy k tomu, jak se postavit ke vznikle chybe (lhostejno zda vstupu ci treba vznikle pri dalsim behu); Tva definice korektnosti je spise bezchybnost (tedy ze kazdemu vstupu poskytuje spravny vystup), korektni program ale neznamena bezchybny program, ale program/funkce reagujici na chyby korektne (jejich manifestaci)

This story is very useful. Really I like it. Thanks for sharing with us.*Air Jordans

A look at things from other people’s ideas, louis vuitton outlet the activity of mind to know other people who never have to worry for their future.