C# Skriva i konsol

Tja, har du 100% state coverage (alla permutationer av alla brancher har körts minst en gång av ett test) på dina unit-tester vilket är ett krav för level A, högsta nivå där en defekt antas kunna vara katastrofal "Catastrophic - Failure may cause multiple fatalities, usually with loss of the airplane.".

Frågan är om de unit-tester du normal skriver ens klarar level C "Failure significantly reduces the safety margin or significantly increases crew workload. May result in passenger discomfort (or even minor injuries).". Där krävs bara att man har 100% line-coverage, en rad som inte körs av något test får inte finnas med, vilket då inkluderar alla felfall, loggning etc.

Varje sats du skriver som ska klara DO-178C måste ha en förklaring till varför den behövs och varför den utför sin uppgift korrekt. Denna förklaring skrivs på ett format som gör att man kan automatisk generera beroendeträd till/från en högnivåbeskriving ner till varje enskild rad. Gissar att du har det i dina program också eftersom de tydligen testas betydligt grundligare än kod för flygindustrin.

Har grävt lite och enda jag hittar är att det baserar sig på statisk och erfarenhet, man hittade helt enkelt oftare buggar i konstruktioner med "?:" än när det skrevs mer explicit. Hittar däremot inte om man jämfört om det är originalförfattaren av koden som oftare gör ett fel eller om det är så att "?:" oftare missförstås av andra när de ska sätta sig in i koden för att göra en ändring/tillägg.

Tycker det är rätt viktigt att separera dessa fall. Det är t.ex. inte speciellt att skriva Perl, men det är fan så svårt att begripa vad någon annan kokat ihop eller ens förstå sin egen kod efter ett tag

Korrekt, det har att göra med att implicit typ-konvertering är i princip alltid en dålig idé (vilket är orsaken till att kodingstandard för C i "manuellt" fått förbjuda sådant i kritiska program). Blir dock en ännu sämre idé ihop med typinferens och hur "?:" normalt beter sig.

Härligt och se att en så simpel fråga kan få igång dessa diskussionerna

Jag tycker det är givet att det är svårare.

Jag är möjligen lite underlig, men ju mer likt vanlig skriven text kod är, desto lättare är det för mig att tolka den omedelbart. Jag har läst betydligt mer fritext än jag har läst kod i mina dagar och jag läser fritext oändligt mycket fortare.

Ja gillar när det är tydligt och konsekvent. Till exempel alltid skriva måsvingar, även när man "inte behöver det" och att inte skriva ? : - Varför ibland skriva på ett sätt och ibland på ett annat? Lika bra att hålla sig till ett sätt, hela tiden, konsekvent.

Eftersom man sällan kan använda sig av shorthanden konsekvent i all kod, tycker jag inte man ska använda det alls faktiskt. Men som sagt, jag gillar verbös kod och konsekvens. Jag tror närapå orubbligt att ju närmare vanligt skrivet eller talat språk man gör sin kod, desto lättare är det att förstå den och att det minskar antalet buggar. Hade jag kunnat hade jag bytt ut alla "<" och ">" med LESS THAN och GREATER THAN t.ex. hehe.

Tror du är inne på exakt varför det har visat sig att "?:" rent statiskt visat sig ge fler buggar än "if (pred)...", det går att konsekvent använda det andra sättet och många utvecklare använder endast den metoden vilket leder till att andra är mer van men den konstruktionen.

Just att en viss typ av konstruktion ska vara konsekvent är en stor orsak till många designval i Go, men fick ändå känslan att anledningen till att man utelämnade "?:" hade mer att göra med vilken typ av konstruktioner man flera gånger sätt folk gjort, konstruktioner som skulle bli mer uppenbart dåliga med "if...".

Det du skriver om måsvingar är en sak som dels är ett krav i alla kod-standarder jag sett för säkerhetskritisk kod + Go just för konsekvens och att det inte helt sällan leder till buggar senare valde att kräva måsvingar även om det bara är en sats i blocket.

Fast vad bevisar du med TDD och BDD? Har kan du garantera 100% line-coverage i alla filer, 100% branch-coverage eller till och med 100% state-coverage i alla funktioner? Kan du garantera det någonstans, i så fall hur kan du formellt bevisa det? Allt detta är saker som standarder för säkerhetskritisk kod har rutiner och specifikationer för, MTBF på kod som är bara är certifierad till t.ex. DO-178C nivå C är så brutalt mycket högre än vad man normalt ser i industrin så även om det finns tester kan man undra vad de testar egentligen.

Vad är man då om man fixar att skriva tester för DO-178C level A? Zen-master of testing

assembly = assembly ?? Assembly.GetEntryAssembly();

if(assembly == null) 
{
   assembly = Assembly.GetEntryAssembly();
}

Som jag skrev innan, vet inte varför det är så. Men statistiken visar tydligen att något gör att det oftare leder till buggar.

var validData = data.Where(d => d.IsValid);

Jag använder i stort sett bara lambda och "aldrig" (man ska aldrig säga aldrig):

var validData = (from item in allData select item where item.IsValid)

Jag skriver även väldigt ofta

if(valid == true)
{

}

Helt onödigt med == true givetvis, speciellt när variabeln heter valid, men det följer lite min lite knasiga besatthet att vara verbal.

Oftast blir det ju dock i motsatsen. !valid skriver jag i stort sett aldrig, utan där blir det närapå alltid valid == false - Tycker att "== false" sticker ut och syns bättre än utropstecknet

Tror du överhuvudtaget inte inser vilken nivå testning ligger på för säkerhetskritiska applikationer. Specflow är säkert helt OK givet den nivån man normal sett håller på källkod, men att jämföra den med testningen som t.ex. DO-178C kräver blir bara fånigt.

Kan du i de tester du skriver ta fram exakt vilka tester som exekverar en viss rad i produkten? Kan du ta fram exakt vilken/vilka tester som får en viss "if()" att ta true resp. false fallet? Kan du bevisa att varenda rad i produkten har körts minst en gång av dina tester, och så krävs, ta fram exakt vilka tester som körde en viss rad?

Samma sak för specifikationer. För varje uppgift som en modul har, kan du ta fram exakt vilka rader som kan tänkas köra för att utföra uppgiften? Eller omvänt, för en valfri rad i koden, kan du plocka fram alla uppgifter/högnivåfunktioner som beror av den raden?

Som aluser påpekar, flygindustrin och även andra grupper där fel i programvara kan orsaka väldigt allvarliga skada har tagit testning till en nivå som majoriteten av de som jobbar med programvara överhuvudtaget inte ens kan föreställa sig.

Om man inte är van vid något så verkar det svårare. Du tycker förmodligen att CLISP är svårare än C++ också, vilket inte nödvändigtvis gör CLISP krångligare i sig.

?: är ett uttryck medan if-then-else är sats(er). De må påminna om varandra men används inte på samma sätt.