Det finns ju gott om exempel i detta forum över vad vi kan kalla "dålig kodningsstil". En del av dessa beror på att det saknas erfarenhet/kunnande och att personen är i en inlärningsprocess, något jag anser är helt OK.
Ett fåtal andra lider kraftigt av
Dunning-Kruger effekten och där är hjälp och råd ju som att kasta vatten på en gås (alt.
Spildte Guds ord på Balle-Lars).
Men det jag mest ser i båda programmering och generell konstruktion är planlöshet. Ett projekt är ju som sådan definierat av att man vill uppnå en specifik funktionalitet på vilket sätt man än kan göra det - men riktigt många planerar inget alls!
Jag minns mitt första kommersiella projekt: styrning av 3 laboratorieugnar i en klinkersfabrik.
Vi fick en 7 sidors beskrivning av vad systemet skulle göra i beställningen. Vi läste på den i 3 dagar och diskuterade utan att fatta ett skvatt. För att hugga den gordiska knuten föreslog jag chefen att anordna ett inspektionsmöte vid den enhet som skulle styras för att hjälpa oss "få ett totalt överblick och kanske snappa upp detaljer som ville hjälpa senare".
Det blev fixat snabbt och medan chefen pratade med chefer hann jag slinka till dom som faktisk jobbade där och fråga hur det fungerade och vad de behövde. Jag fick mycket tydlig, konkret och mycket användbar information som kunde formuleras på få rader och som gav mening. Jag noterade detta vid återkomst till kontoret och vi jämförde med de 7 sidor och det var inte många rätt där kan vi säga.
Nåväl, vi byggde det vi skulle, programmerade och min paranoia fick mig att räkna på allt som kunde gå fel och sedan säkra mot det. Vid uppstart var det 1(!) bugg som rent faktisk var för att det var kopplat fel temperatursensor till fel ingång men det var enklare att lösa i mjukvaran.
Vi hann inte med att skriva manual innan driftstart så chefen skulle åka dit dagen efter monteringen och förklara, vi höll på att skriva som en galen på manualen just då. Då han kom dit 10:00 körde alla 3 ugnar i full drift och då han kollade om det var problem fick han veta att det var ju så enkelt att använda ett det hade tagit dom 5 minuter att starta den första ugnen, det tog 3 minuter av de 5 att mata in siffrorna som beskrev bränningskurvan.
Vi skrev aldrig manualen, behövdes inte. Projektet körde oändrad i 5 år varefter de ville ha en ändring: fler platser i biblioteket till kurvor. Det klarade chefen vid att leta upp källkoden, ändra "10" till "25" (antal kurvor i minnet) och kompilera. I kommentaren stod det att det maximalt var plats för 401 kurvor...
Och vad är då allt detta pladder? Jo, planering!
Man ska definiera ett projekt! Visst, många hobbyprojekt växer fram eftersom man skaffar grejer, lär sig mer eller liknande vilket betyder att det hela kan bli mycket virrigt i slutändan - och det är egentligen OK under utvecklingsstadiet och "proof of concept"-fasen.
Men för sin egen sinnesfrids skull ska man rensa/strukturera program ordentligt och skriva kommentarer medan man minns vad och varför ("MISO: PORTA1, MOSI: PORTA0 pga. xxx hårdvaruproblem/hade lödd så, kan bytas.").
En del verkar tro att man ska skriva kommentar för varje rad men en kort beskrivning av vad en funktion är till för är alldeles utmärkt.
I projektet jag beskrev ovan började jag med att tänka ut hur uppgiften kunde lösas.
Sedan skrev jag källkod i form av en massa delfunktioner som jag kunde räkna ut behövdes (<läsa knappsats>, <1-sek interrupt>, <räkna ny temperatur baserat på gammal temperatur, lutning och tid> osv.). För varje delfunktion skrev jag namnet på den och lite kommentarer om vad den skulle göra - och sedan gick jag vidare till näste, ingen programmering just då.
På det vis kunde jag hålla en översikt utan att tappa bort mig i detaljer, något mitt handikapp annars gör mig benägen att göra.
Att en enhet fungerar betyder inte att man har en chans att minnas vad/hur om 6 månader och det MÅSTE man veta för även hobbyprojekt kan vara värdefulla - och gå sönder. Och då kan man behöva göra ny eller liknande.
Samma sak är det med programmeringsspråk: vad behöver man egentligen?
* Är det ett språk till en begränsat hårdvara eller är det mycket kraft av alla former i systemet?
* Administrativt eller blinka LED?
* Tunga uträkningar?
* Speciella optimeringar?
Att utnämna C till att vara <SPRÅKET> är fel, det finns andra språk som ger andra fördelar där de behövs.
Har inte läst igenom MISRA men ja, C är ett kraftfullt språk där man kan skjuta sig i foten på ett subtilt sätt så det kräver en del egenkontroll av att variabler rent faktisk kan klara de värden man vill peta i dom eller som uträkningar kan ge osv.
Lika starkt det är, lika effektivt kan man såga av grenen man sitter på. Men det betyder inte att andra språk är "bättre", de kan dock vara skyddad bättre mot de normala fel man gör.
Så i projektplaneringen ska ingå krav på en utvärdering av om språket klarar jobbet utan trix.
