Hur planerar och strukturerar ni ett större program?

[Magnus_K]

Om ni planerar att göra ett större program, eller i alla fall ett program som skulle kräva lite strukturering och planering, ungefär hur hade det sett ut?

Skapar något slags "flowchart" eller en innehållsförteckning? Skapar man biblioteksfiler (om nödvändigt) allt eftersom eller börjar ni med detta?
Använder ni något slags mappsystem i IDE:et?

Det kommer bli mer följdfrågor men väldigt intresserad att höra hur ni lägger upp planeringen.

[sodjan]

1. Ha en klar bild av vad problemet är och vad programmet ska göra.
2. Skissa funktionen med papper och penna.
3. Identifiera oklara punkter/tekniker och testa dessa separat. "Proof-of-concept".
4. Så ihop det hela så som det är tänkt.

Om det finns någon annan "mottagare" än sig själv, så får man så
klart ta hand om den kommunikationen också...

Helt kort...

[SeniorLemuren]

Som sodjan skrive >>1. Ha en klar bild av vad problemet är och vad programmet ska göra.<<

Kravspecifikation är det viktigaste i hela processen. Den kan jämföras med notorna för en musiker. När allt finns korrekt nerskrivet så som kompositören vill att det skall låta är det bara att spela.

Precis som i musiken programmerar man ett stycke i taget och testar att allt stämmer enligt kravspecen.

[Larsson90]

Punkta upp vad du vill göra så du får en klar bild av det hela. Börja med övergripande punkter och bryt ner dem till mindre.
Ta fram flowcharts och/eller pseudokod (kan också brytas ut i mer/mindre detaljerade vyer). Mockups är också bra, speciellt om du gör något grafiskt.

Brukar arbeta efter följande:

1. Få det att fungera
2. Strukturera det snyggt. Antingen via refaktorering eller skiva om allt (beror på hur bra du skrev det från början). Gör att koden är lätt att underhålla.
3. Få koden att prestera

[Icecap]

Mitt handikapp gör det svårare för mig att överskåda stora funktioner. Jag har därför lärt mig att bryta ner allt till hanterbara storlekar som kan avklaras.

Ett exempel är de enkla uppgifter: läsa och skriva inställningar i EEPROM.

Jag löser först själva hårdvarainterfacen, ser till att den fungerar. Är det ett kretskort som ska användas till en del olika funktioner är detta ju basalt och viktigt - och återanvändbart.

Sedan bygger jag en "läsa EEPROM block" & "skriva EEPROM block" som ju rent faktisk gör jobbet.

Och sedan gör jag en enkel funktion för de saker jag ska utföra:
* Config_Read(); (ofta #define EEPROM_Read(*Config, CONFIG_START_ADDRESS, sizeof(Config);)
* Config_Write(); (ofta #define EEPROM_Write(*Config, CONFIG_START_ADDRESS, sizeof(Config);)
* Statistic_Read(WORD Index, T_STATISTIC* Statistic_Data); Inte sällan en #define där också.
* Statistic_Write(WORD Index, T_STATISTIC* Statistic_Data); Inte sällan en #define där också.

När jag sedan har alla dessa byggblock klar och testade får jag bygga på. Koppla ihop de saker som behövs och där jag omedelbart kan se att jag behöver en "större" funktion, dessa skapar jag och "kopplar ihop" och plötsligt upptäcker jag att nu är det klart!

Men utan att veta exakt vad jag ska åstadkomma till att börja med är det inte värd att ens börja. Visst, man kan fixa hårdvara-interface osv, alla de rudimentära funktioner men sedan är det stopp.

Men när man vet vad som ska åstadkommas är det ganska enkelt.

Om man har många sidolöpande funktioner kan det vara mycket smart att först klura ut hur de ska skötas.
Ska det vara interrupt?
Time-share?
State-machine?
Main-loop nivå?

När detta är klart kan man bygga upp en funktion åt gången och testa dom, steg för steg.

[Gizmo]

De få större program jag har skrivit har jag faktiskt satt mig med papper och penna och ritat lite delar av programmet. Därefter funderat på vilka delar som är viktigast eller mest komplicerade att få att fungera bra och så gjort dem först. Kanske låter konstigt det där med papper och penna, men för mig funkar det bättre än visio/flödesidagram, säkert olika för olika människor det där.

[sodjan]

Jag brukar säga att man bör:
- Designa uppifrån och ner. Börja med de stora dragen.
- Programmera nerifrån och upp. Börja med detaljerna.

Om det finns tveksamma detaljer så bör dessa kontrolleras tidigt
så att man inte måste backa ur en massa senare i projektet.

[qx5]

Man kan skriva ihop en prototypprogram för att se om man fått konceptet rätt. Då brukar man rätt lätt upptäcka aspekter man inte tänkte på innan. När man fått fatt på alla de erfarenheterna så börjar man på helt ny kula.

[Lennart Aspenryd]

Tänkte svara Visio och Modulärt, men kom på att jag är utloggad

[sodjan]

Visio är säket helt OK för att dokumentera det man har
kommit fram till med penna och papper. Det kan ju
finnas behov av att presentera det för andra också.

[Magnus_K]

Ni ska verkligen ha jättetack för alla snabba och bra svar!

Tänkte sammanfatta lite senare men har någon mer fråga.

Vad använder ni för tekniker/metoder/tänk för att hålla huvudprogrammet så överskådligt och lättläst som möjligt?
Då jag själv har väldigt liten erfarenhet av det här så tycker jag ibland att en del program blir för svårlästa med alldeles övertygad om av dom går att få mer lättlästa.

En sak jag tänker på är hur man kan underlätta navigering i koden.
Finns det tex IDE:n med möjligheter till att hyperlänka eller annan navigeringshjälp? Kanske lite onödig funktion för er erfarna med för en annan som bläddrar runt i koden som en tok så hade någon slags hjälp underlättat.

[sodjan]

Nu gäller det ju nya program, men om jag har önskemål om ändringar i något
äldre program, så brukar jag helt enkelt skiva ut det. Sen blir lite koll på det
i en solstol, soffan eller som alternativ till en bok på kvällen...

Gäller det nyutveckling så finns det ju verktyg som har fina funktioner.
Jag har nyligen försökt köra MPLAB-X lite mer och där finns ju massor
av funktioner för att länka från en användningen av en funktion till
dessa definition eller implementering. Alltså NetBeans i det fallet.

Men generellt gäller kanske att inte bygga i större pusselbitar än vad
man klarar att hantera som en enhet. Sen gäller det bara att ha tydliga
och bra gränssnitt mellan bitarna så att man inte ständigt behöver
hoppa mellan dom. När en rutin fungerar, så räcker det med att
ha gränssnittet tillgängligt.

[Virror]

Som sodjan säger så är interfacet väldigt viktigt om man vill ha det lätt att följa.
Tydliga namn på variabler och funktioner, kommentarer ska ej behövas utom blockkommentarer för varje funktion, undantag finns såklart om man tex har formler eller andra små saker som kan behöva förtydligas.
Korta funktioner och korta filer gör det också mycket enklare att följa.

[Icecap]

En sak som kan hjälpa ordentligt: rätt namn på funktioner!

Ger man rätt namn på funktioner är programmet nästan(!) självkommenterande. Såklart bör parameter som skickas ha rätt namn också, det hjälper väldigt mycket när man ska läsa programmet.

Men sodjans "inte bygga större pusselbitar än man kan hantera" är alldeles korrekt. Och de pusselbitar ska gärna vara kommenterat med vad funktionen gör, vad den behöver och vilka värden (om någon) den ändrar.

Personligt kan jag få spader när man ser "svenska" namn på funktioner, jag har konsekvent engelska namn då jag anser att "goer_saahaer" ser vidrigt ut.

Jag inleder alltid med versal. Jag har även versal/gemen-koll aktiverat.

Om en funktion använder ett antal variabler brukar jag samla dom i en struct, då blir det ganska tydligt vad som används i olika funktioner. Detta säkrar oftast mot att man använder en "skräpvariabel" för en uträkning - och det då visar sig att man mindes fel och variabeln var viktig.

Jag har börjat luta mot att ha en fil för varje hårdvarafunktion, t.ex. så att en UART tas om hand i en egen fil. Det gör det oftast enklare att återvinna kod men det snyggar till det hela ganska mycket. Är det knas med t.ex. UART'en kan man öppna just den fil, kolla vad som kommer in och vad som går ut och då se var problemet finns och hur det ska lösas.

Med Eclipse kan man få den hjälp med var saker är definierat osv.

[Magnus_K]

Verkligen bra tips!

Jag håller med dig sodjan, printar mycket hellre ut och lutar mig tillbaka någonstans. Av någon anledning finner jag det enklare att direkt kunna göra små justeringar/kommentarer med pennan än digitalt, med det är ju givetvis upp till smak!

Har provat att göra som du börjat luta mot Icecap; att ha en separat fil för en hårdvarufunktion. Det tyckte jag verkligen om så det fortsätter jag nog med.

Det som ni/du nämner Virror så är nog blockkommentering rätt väg att vandra. Jag har tidigare kommenterat i stort sett radvis men tittar man på det nu så ser man verkligen hur plottrigt det blir. Nej, blockkommentarer med funktionsbeskrivning, tydliga funktions/variabel-namn blir bra.

Hmm, vet att någon (kan ha varit jesse) som i en annan tråd tipsade om ett dokument som var lite programmeringsstandard eller vad man kan kalla det. Det kan till och med varit på svenska. Är det någon som känner igen vad jag pratar om och kan minnas mer?
Vad jag har för mig var det ett väldigt bra dokument som nämnde mycket om när och var man skulle använda versaler med mera.