Skriva ut array, varför inte bara på ett sätt?
Re: Skriva ut array, varför inte bara på ett sätt?
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.
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.
Re: Skriva ut array, varför inte bara på ett sätt?
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...
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...
Kod: Markera allt
DISPLAY "MARKERING (1 POS) : " WITH NO ADVANCING.
ACCEPT ARTMRK.
MOVE ARTPOST TO IO-BUFFER.
PERFORM YK-ADD.
IF IO-RETCODE = 0 THEN
DISPLAY " "
DISPLAY "NY POST ÄR NU SKAPAD : " IO-BUFFER
PERFORM MM-SKRIVA-UT
ELSE
DISPLAY "FEL VID SKAPANDE AV NY POST!"
PERFORM PP-FEL
END-IF.
-
- Inlägg: 1397
- Blev medlem: 29 januari 2011, 21:06:30
- Ort: Lapplandet
Re: Skriva ut array, varför inte bara på ett sätt?
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.
Re: Skriva ut array, varför inte bara på ett sätt?
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...
ä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...
Re: Skriva ut array, varför inte bara på ett sätt?
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
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
Re: Skriva ut array, varför inte bara på ett sätt?
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.
Re: Skriva ut array, varför inte bara på ett sätt?
Alltså, den översta exemplet förstod jag direkt, väldigt läsbar C-kod (det undre ser ut som nån läskig C++)Mr Andersson skrev: <bortklippt>
Bra kod är självdokumenterande.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(int i=0; i<sizeof(tmrs)/sizeof(*tmrs); ++i) { disable_int(tmrs[i]); }
Ingen kommentar behövs för att förklara att man stänger av interrupts för alla startade timers.Kod: Markera allt
for(auto timer : running_timers) { timer->disable_interrupt(); }
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.
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.
Re: Skriva ut array, varför inte bara på ett sätt?
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).svanted skrev:betyder det att en person inte kan skriva buggfri kod?
alltså utan att den granskas och avlusas av flera andra.
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.
Re: Skriva ut array, varför inte bara på ett sätt?
Det är så de flesta buggar introduceras:)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.
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
Re: Skriva ut array, varför inte bara på ett sätt?
Svårt att inte posta denna länk: https://www.infoq.com/presentations/Nul ... ony-Hoare/
Re: Skriva ut array, varför inte bara på ett sätt?
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.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.
Re: Skriva ut array, varför inte bara på ett sätt?
Och då har du förstått fel och hakat på en vandringsskröna.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.
För den som är intresserad av fakta istället för "kill gissningar" så är denna länk ganska intressant.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.
Re: Skriva ut array, varför inte bara på ett sätt?
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?
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?
Re: Skriva ut array, varför inte bara på ett sätt?
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.
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.