Svenska ElektronikForumet

Mr Andresson, dina exempel är nog de dummaste jag läst på länge.

Naturligtvis,:


int x= 3; //x är en räknare som används för att hålla reda på "xyyz", den uppdateras när "abc" är lika med "fgh", orsaken till att den initialiseras till 3 är...….

Det existerar ingen självkommenterande kod, möjligtvis i stunden hos programmeraren som skriver den, efter ett par år, så har programmeraren fullständigt glömt av hur, när och varför, än svårare är det för andra att försöka förstå hu programmeraren en gång tänkte, om han ens själv vet det efternågot år.

Den här koden skrevs för 33 år sedan och jag har inget problem
att varken läsa den eller att förstå vad den gör. Det är väl så
nära självkommenterande kod som man kan komma...

Oj oj, 12 rader kod. Enligt Tomas måste du då ha 1200 rader kommentarer för att det överhuvudtaget ska gå att förstå den.

Kanske det... Min poäng var väl mer att, hur "lättläst" en kod
är, till en del beror på vilket språk den är skriven i. En del språk
(programmeringsspråk) är mer likt talat språk än andra...

Tja men inte enbart.
Hade TomasL valt att kalla sin variabel "x" för "xyyz_counter" el.likn. så hade han kunnat minska mängden nödvändiga kommentarer

Jo, men har man ett par hundra tusen rader kod, i ett projekt, så är det inte helt enkellt att komma ihåg vad respektive rad gör.

Mr Andersson skrev: <bortklippt>
Bra kod är självdokumenterande.

Kod: Markera allt

for(int i=0; i<sizeof(tmrs)/sizeof(*tmrs); ++i)  {
  disable_int(tmrs[i]);
}

Skriver man kod liknande ovan förstår jag att man tycker att kommentarer ska finnas överallt. Helt omöjligt att förstå vad som händer.

Kod: Markera allt

for(auto timer : running_timers) {
  timer->disable_interrupt();
}

Ingen kommentar behövs för att förklara att man stänger av interrupts för alla startade timers.
Då skriver man istället en kommentar om varför man måste stänga av interrupts just här.
Ett kommentar-block ovanför loop-blocket. Att kommentera varje rad individuellt är bara ordbajseri som sänker produktiviteten och skapar frustrerade programmerare.

Alltså, den översta exemplet förstod jag direkt, väldigt läsbar C-kod (det undre ser ut som nån läskig C++)
Möjligen att använda typerna i sizeof-istället för instanserna.

Jag tycker att man ska förutsätta att man själv och den som ska läsa koden kan språket och de normala konstruktionerna man använder.
Kommentera gör man när saker inte är uppenbara eller till synes görs i konstig ordning eller till synes ologiskt, men att det finns en anledning.

I övrigt kommer variabelnamn och kontext att förklara väldigt mycket vad programmet gör. Sedan behövs det kanske ett dokument som på högre nivå beskriver hela uppbyggnaden och uppdelningar/modulariseringar så man förstår vad koden sedan ska göra.

+1 på det

svanted skrev:betyder det att en person inte kan skriva buggfri kod?
alltså utan att den granskas och avlusas av flera andra.

Det är lite definitionsfråga. Visst kan en person lyckas skriva buggfri kod. Men det kan ju då lika gärna handla om tur som kompetens. Och tur och otur här ihop (det handlar om sannolikhet).

Så om sannolikheten att en person skriver buggfri kod är 90% så är det 10% sannolikhet att personen skriver en bugg. Om du ska flyga, tycker du det räcker med 90% sannolikhet att planet inte störtar? :)

Därför har man metoder för att skriva kod som har för avsikt att minimera andelen bugga. Man följer strikta regler för hur koden ska skrivas, man har både andra och tredje par som granskar koden och man kräver att varje "förgrening" i koden ska kunna testas (verifieras). Och sen kör man verifieringar av koden, d.v.s. man testar varje litet kodsegment för sig och kollar att det beter sig som förväntat. Sen slår man ihop kodsegmenten och testar den tillsammans (då vet man att segmenten fungerar som de ska "invändigt", så man testar gränssnittet mellan segmenten.

Sen är det klart att man inte gör så för alla typer av kod, man får bestämma sig för hur stor sannolikhet för fel man accepterar. Det är skillnad på en webbläsare och mjukvaran i en rymdfärja.

I vissa fall så litar man ju inte ens på koden utan kör två eller tre separat skrivna koder parallellt. Så är ju t.ex. fallet i JAS. Där är det tre processorer som kör varsin kod. Såvitt jag förstått är all kod skriven av tre separata team, jag undrar om man inte t.o.m. använd olika språk för att vara säker på att samma bugg inte ska kunna finnas i två av programmen.

adent skrev: Jag tycker att man ska förutsätta att man själv och den som ska läsa koden kan språket och de normala konstruktionerna man använder.

Det är så de flesta buggar introduceras:)

Antaganden är "livsfarligt".

Här finns lite bra läsning. Det är ingen som hittar på ett sånt här massivt dokument utan anledning.

https://resources.sei.cmu.edu/downloads ... 16-v01.pdf

Svårt att inte posta denna länk: https://www.infoq.com/presentations/Nul ... ony-Hoare/

Jag tycker att man ska förutsätta att man själv och den som ska läsa koden kan språket och de normala konstruktionerna man använder.

Då förutsätter du att den som tar över efter dig tänker på exakt samma sätt som du själv gör, vilket han/hon garanterat inte gör, och därmed introducerar du en mycket stor risk för att det blir ett fel i programvaran.

Nerre skrev: I vissa fall så litar man ju inte ens på koden utan kör två eller tre separat skrivna koder parallellt. Så är ju t.ex. fallet i JAS. Där är det tre processorer som kör varsin kod. Såvitt jag förstått är all kod skriven av tre separata team, jag undrar om man inte t.o.m. använd olika språk för att vara säker på att samma bugg inte ska kunna finnas i två av programmen.

Och då har du förstått fel och hakat på en vandringsskröna.

Samtliga insignaler delades mellan kanalerna via CCDL, (Cross Channel Data Link), så alla insignaler fanns tillgängliga i alla kanaler. Detta innebar också att samma programvara kunde användas i alla tre kanalerna. En viss anpassning krävdes dock för kommunikation med flygplanets övriga system, vilka inte var trekanaliga, det gällde luftdata, systemdator och navigering.

För den som är intresserad av fakta istället för "kill gissningar" så är denna länk ganska intressant.

Det är ju synd att jag inte har nån länk till den artikel jag läste för många år sen som var skriven av en person som just varit involverad i koden för JAS styrsystem.

Men det där stycket handlar väl inte om den slutliga lösningen? Det verkar handla om de första provflygningarna? Den är ju skriven i imperfekt?

Jag är också osäker på om det handlar om samma sak. Jag hittar info om att man använda tre "bussar" på grund av prestandaskäl, men det är ju inte samma sak som att saker var triplade för redundans?

Allt finns i länken.
Det är ju SAAB's egna sida så du får nog tvingas ha lite tilltro till den.

Att man skriver i imperfekt är för att man beskriver en resa.

Styrautomat 11 (SA11) är den som gäller fortfarande (Osäker på Gripen NG dock)

Varje sk kanal (3st) har en Texas TMS320C30 som in/ut-data processor.
Beräkningsprocessor är Motorola 68040
Sensorer är generellt duplicerande.
Kanalerna är voterade

Den här konstruktionen handlar ej om kod/buggar/felaktig kompilering utan om ren redundans gentemot sensorfel och IO fel.
Att ha tre olika koder, skrivna i tre olika språk vore troligtvis helt kontraproduktivt (3 upphöjt i två -1 * potentiella felutfallet) om du funderar lite på det.

Man chansar med koden till ett styrsystem för ett instabilt flygplan.
Förutom mänsklig granskning, så sker givetvis rigorösa automatiska tester.

Om man är perverst intresserad så är här ett litet exempel på felinjecering i MACCS systemet LÄNK
Observera att det är experimentell verifiering. Därmed inte sagt att denna metod används skarpt.