Tool om programma ordelijk te houden en te beginnen

Ik ben geen programmeur, nooit geweest.
Is het minste van mijn interesses bij een project.

Daarom verbaasd het mij soms dat men er in slaagt om grote projecten mooi op te bouwen (het is mijn core business niet).

Daarom mijn vraag om tips..

Bestaat er gratis visualisatie software waar ik een programma dat ik wil maken in stukjes kan kappen, en daar weer kleinere details zetten?

Of hoe kan ik dat voor eens en voor altijd op een wat "lean" manier doen?.

Nu begin ik aan iets, tracht zo veel mogelijk commentaren er bij te schrijven om later terug aan uit te kunnen, maar dan blijft dat weer weken liggen en weet ik niet meer waarmee ik bezig was.

Soort van flowcharts waarin ik details kan opnemen of iets dergelijks en waaruit ik later terug kan vinden uit welke stapjes die weer gebouwd zijn?

Arco

Special Member

Flowcharts kunnen handig zijn. Ikzelf maak ze nooit omdat ik daar vreselijk in ben... ;) (wel gebruik ik ze van anderen)
Beste is om de software op te knippen in subroutines die een bepaalde taak doen. (keyboard lezen, leds aansturen,...)
Als je die allemaal apart hebt getest, kun je ze gaan samenvoegen...

Arco - "Simplicity is a prerequisite for reliability" - hard-, firm-, en software ontwikkeling: www.arcovox.com

Ja dat doe ik.

Maar ik heb niet echt meer de inzichten als ik een project een paar weken heb laten liggen (hobby dus).

Daarom, visualisatie werkt schijnbaar..

Ook handig is om lagen aan te brengen.

Voorbeeldje: een I2C acellerometer. Laagste niveau doet dingen met pins en de I2C module van de cpu. Daarboven een laag die registers in de chip kan lezen en schrijven. Dan een laag die betekenis aan de registers geeft. En dan de functies van wat je daar dan mee wil doen.

Je hoofdprogramma roept dan iets van zijn_we_aan_het_vallen() aan,
Die gebruikt dan x_accel(), die dan accel_read_reg(X_REG) doet en dan read—reg die i2c_write_byte en i2c_read_byte gebruikt.

Zo is ieder niveau maar een paar regels, maar wel in 1 oogopslag te begrijpen.

Het wordt onbegrijpelijk als je de vallen routine gaat schrijven als i2c_dr = 0x54; // send acc addr. While ... // wacht op klaar. I2c_dr = X_REG; ... gaat schrijven. Nu lopen alle niveaus door mekaar en is het later lastig te zien wat je ook al weer aan het doen was.

De code is dan "leesbaar" op alle niveaus. Zelden commentaar nodig.

code:


if (zijn_we_aan_het_vallen () ) 
    harddisk_uit ();

code:


int zijn_we_aan_het_vallen () 
{
 ax = x_accel ();
 ay = y_accel ();
 az = z_accel ();
 ta = sqrt (ax*ax + ay * ay + az*az);
 return ta < 0.1;
}

code:


float x_accel () 
{
 return SCALE * read_accel_reg (X_ACCEL);
}

code:


int read_accel_reg (int regno)
{
  int rv;
  i2c_start ();
  i2c_send_byte (ACCEL_ADDR + WRITE);
  i2c_send_byte (regno);
  i2c_restart ();
  i2c_send_byte (ACCEL_ADDR + READ);
  rv = i2c_read_byte ();
  i2c_stop ();
  return rv;
}
four NANDS do make a NOR . Kijk ook eens in onze shop: http://www.bitwizard.nl/shop/

Dat is het typische aan programmeren, langere tijd laten liggen en daarna veel moeite hebben om zich er weer in in te leven.

Ik schrijf per project alle denkbare gegevens op papier, krabbels, tekeningen, gebruikte formules enz.. het is een wirwar van gegevens en alles door elkaar en soms ook wel copies van aansluitgegevens ook al staan die op de computer.

En raar maar waar als ik dat dan na een langere tijd terug oppak dan komt alles heel snel terug en hoe ik eraan gekomen ben.
Flow en andere charts werken bij mij niet, zijn soms nog abstracter dan het programma zelf en vragen veel teveel werk.
En, zoals je nu al doet, veel commentaar bijschrijven

Iedereen is verschillend, iemand anders werkwijze overnemen zal zeer moeilijk zijn, het is bij wijze van spreken al te laat.

LDmicro user.

Het inderdaad een bekend probleem. Ik had vroeger op school een programma'tje dat heette flow o.i.d. Het was een heel eenvoudig stukje software waar je op een overzichtelijke manier je beslissingsbomen in kon vastleggen Ik geloof dat je er alleen maar beslissingswiebertjes en actieblokjes mee kon tekenen en uiteraard verbindende (stroom)lijntjes met een pijltje.

Het was echt heel duidelijk en een jaar later begreep je meteen wat er gebeurde. Later had ik een programma dat heette sourcerer. Dat kon van een bestaand programma een flowdiagram maken. Dat heb ik wel eens gebruikt om ergens een virus uit te destilleren.

Dit soort van software mis ik eigenlijk best wel eens. Ik heb nu een arduino programma gemaakt dat hapert en vervelend is omdat de interrupts elkaar bijten. Ik maak gebruik van de standaard arduino i2c library en een paar losse hardware interrupts. Ik weet niet hoe die arduino library werkt. Waarschijnlijkt maakt die ook weer gebruik van interrupts en gaat daar af en toe iets fout. De stack zal wel craschen ofzo. En ik heb helemaal geen zin om dat uit te gaan zoeken.

Af en toe denk ik wel verlangend terug aan de tijd dat ik hard in machine taal programmeerde. Dan kon ik gewoon het interrupt mask en het prioriteiten registers zetten en alles netjes gestroomlijnd laten verlopen. De interrupts rollen dan niet willekeurig over elkaar heen. Info over de arduino library's vind ik ook moeilijk toegankelijk en lastig vindbaar. Maar het zal wel aan mij liggen. Niemand heeft er verder problemen mee.
Maar misschien moet ik ook maar weer in machinetaal gaan programmeren. Dan is elke opdracht tenminste zeer duidelijk.

Het handigste is toch echt in de code zelf duidelijk werken:

Geen loops of if elses die meer dan 5 - 10 regels doorlopen.

Geen nietszeggende variabelen als:
Count, x, i, a.

Code kort houden:

If leessensor(TEMPERATUUR)>MIN_TEMPERATUUR

Leest sneller dan:

X = readInputPin(3)
Y = 5

If X>Y

Etcetera.

Grote projecten werken vaak modulair. Er is dan wel discipline nodig. Als een module iets niet ondersteund dan is het meer werk alles aan te passen dan direct in de spaghetticode iets erbij te proppen.

bprosman

Golden Member

Ondanks dat het (maar) hobby is maak ik bij een project nog steeds een "Design specification".

Wat moet het ding doen, wat zijn de ingangs-signalen, wat komt er op de uitgang etc. Vervolgens schrijf ik de software functionaliteit uit , de low-level routines zijn er meestal al wel en/of verzamel je in de loop der jaren.

Dit heb ik altijd een hele goede pagina gevonden:
https://airborn.com.au/method/index.php

De jongere generatie loopt veel te vaak zijn PIC achterna.
Anoniem

Zelf maak ik veel gebruik van DoxyGen.
Deze genereert documentatie van je sourcecode en de comments die
je in je code opneemt.
Kan zelfs flowcharts en statemachines genereren op basis van bepaald
gestructueerde comments die je invoegt.

Je moet er ff tijd in steken maar je krijgt er veel voor terug.

Just my 2 cts.

Allemaal bedankt.

Ik onthou dat ik beter manueel (op papier) alles noteer.
Ben ik wel wat chaotisch voor.. maar ga het proberen.

De tools die jullie voorstellen ga ik wel eens goed bekijken, alsook de webpage om de projectspec's op te lijsten.

Ik ga proberen wat meer orde in de chaos te steken. >:)

Die tools gaan je echt niet helpen. Da's mooi als je professioneel met software bezig bent, ook voor documentatie, reviews en zo.
Ik zou gewoon een logboek bijhouden waar je vanalles in noteert. Nou zou ik dat elektronisch doen. Handvol links copieer je makkelijker in een file dan dat je het opschrijft. En hou per "project" en directory structuur bij waar je alles in opslaat. Daarmee moet je eea toch makkelijk weer terug kunnen vinden. Voor de rest zit het in je hoofd, daar kun je ook aan werken trouwens.

"We cannot solve our problems with the same thinking we used when we created them" - Albert Einstein
Arco

Special Member

Vaak wordt er ook zinloos commentaar bij code geschreven, wordt er alleen onoverzichtelijker door. Bijv:

code:

Relay1 = ON   'relais 1 gaat aan

Als je bij een blok(je) code omschrijft wat dat doet heb je daar veel meer aan...

Arco - "Simplicity is a prerequisite for reliability" - hard-, firm-, en software ontwikkeling: www.arcovox.com

Op 18 augustus 2019 18:30:36 schreef MJU:
Ik onthou dat ik beter manueel (op papier) alles noteer.
Ben ik wel wat chaotisch voor.. maar ga het proberen.

Moest je mijn krabbels zien dan zou je denken hoe geraakt die eruit ;) maar dat is nu eenmaal mijn werkwijze.
Tekeningen maken met de computer duurt mij te lang, met de vrije hand gaat het veel veel sneller .. en ik heb een goede scanner.

Op de computer worden alle documenten van dat project in 1map gezet, als ik die map opendoe staat alles wat ik nodig heb gehad(of heb) om dat programma te maken, gemaakte foto's, scans, filmpjes, inclusief stukken van datasheets en natuurlijk de sourcecode en de gecompileerde files.

In principe moet ik dan nergens meer gaan zoeken wat ik bv 10j geleden heb gemaakt of gebruikt voor dat project, alles staat in die map.
Als je dat vanaf het begin van het project doet is het heel makkelijk te onderhouden en na een tijdje krijg je daar een soort routine in.

LDmicro user.
High met Henk

Special Member

er is ook DOXYGEN

heb er wel eens naar gekeken, en het is EEN idee.

E = MC^2, dus de magnetische compatibiliteit doet kwadratisch mee???
big_fat_mama

Zie Paulinha_B

Er is hierop geen algemeen antwoord mogelijk, het hangt heel erg af van de programmeertaal en van het O/S (als er al een is).

Voorbeeld: In Unix, en al wat er is van afgeleid tot en met Raspbian, is het een uitgangspunt om een totaalopdracht zoveel mogelijk op te delen in deelprocessen, die elks onafhankelijk draaien, en met elkaar communiceren via bestanden en/of pipes en/of semaphores. Andere O/S, begonnen als single-tasking, maken nog steeds 1 executable die dan alles tegelijk/doorelkaar moet doen.

Ook: als je C schrijft kun je stukken broncode afzonderen in "include"-bestanden; erg handig, als je complexe dingen schrijft. Je hoofdprogramma omvat dan nog maar enkel de hoofdlus, of zelfs dat niet, en een reeks includes. Iet of wat assembler kan dat ook wel aan, denk ik. In python gaat dat niet, daar kun je enkel nog je functiedeclaraties in een eigen library stoppen en die dan importeren.

Als illustratie: ik werk aan een eigen "moving map" onder Raspbian; dat omvat enerzijds een python script, dat gnss-data inleest en wegschrijft in enkele bestandjes, en anderszijds een redelijk complex C-programma dat verschillende lagen van de map op scherm brengt, voor elke laag is er een #include. En de hoofdlus begint natuurlijk met het lezen van de gnss-informatie uit de bestandjes die de python geschreven heeft.

En enkele bedenkingen bij vorige bijdragen:

Als je bij een blok(je) code omschrijft wat dat doet heb je daar veel meer aan...

Inderdaad. Bij wijze van boutade kan men stellen dat perfect geschreven code helemaal geen commentaar bevat, wegens overbodig. Bij mij kun je nog wel eens iets lezen als "ptr-- //pointer was reeds impliciet verhoogd maar dat hoeft hier niet"

Moest je mijn krabbels zien dan zou je denken hoe geraakt die eruit

Dat maakt me benieuwd :) Maar inderdaad het is allemaal maar een kwestie van gewoontes. Zichzelf een beetje opvoeden, af en toe...

[Bericht gewijzigd door big_fat_mama op zondag 18 augustus 2019 20:26:32 (18%)

hoe beter de vraag geschreven, zoveel te meer kans op goed antwoord

Op 18 augustus 2019 19:56:26 schreef High met Henk:
er is ook DOXYGEN

heb er wel eens naar gekeken, en het is EEN idee.

Het nodigt uit om commentaar/documentatie te schrijven waar je helemaal NIETS aan hebt.

code:


/**
 * @name    Serial status flags
 * @{
 */
#define SD_PARITY_ERROR         (eventflags_t)32    /**< @brief Parity.     */
#define SD_FRAMING_ERROR        (eventflags_t)64    /**< @brief Framing.    */
#define SD_OVERRUN_ERROR        (eventflags_t)128   /**< @brief Overflow.   */
#define SD_NOISE_ERROR          (eventflags_t)256   /**< @brief Line noise. */
#define SD_BREAK_DETECTED       (eventflags_t)512   /**< @brief LIN Break.  */
/** @} */

Wat heb ik aan het commentaar dat dit constantes zijn? waar worden ze gebruikt? Wat heb ik aan de documentatie "Parity." bij de constante "SD_PARITY_ERROR". De code geeft in ieder geval aan dat het een ERROR betreft.

four NANDS do make a NOR . Kijk ook eens in onze shop: http://www.bitwizard.nl/shop/
buckfast_beekeeper

Golden Member

Op 18 augustus 2019 10:43:15 schreef K7Jz:
Het handigste is toch echt in de code zelf duidelijk werken:

Geen loops of if elses die meer dan 5 - 10 regels doorlopen.

Geen nietszeggende variabelen als:
Count, x, i, a.

Code kort houden:

If leessensor(TEMPERATUUR)>MIN_TEMPERATUUR

Leest sneller dan:

X = readInputPin(3)
Y = 5

If X>Y

Etcetera.

Grote projecten werken vaak modulair. Er is dan wel discipline nodig. Als een module iets niet ondersteund dan is het meer werk alles aan te passen dan direct in de spaghetticode iets erbij te proppen.

Over de nietszeggende variabelen ben ik het niet 100% eens.

c code:


For(int x=0, x<100; x++){
    System.out.println(x);
}

Wie daar niet mee overweg kan moet maar wat anders gaan doen.

@TS: gebruik zinvolle namen.
Zoals hierboven ook al aangehaald geen zinloze commentaar. Bij functies en procedures zet ik er wel kort boven wat de functie/procedure doet wat de zaken zijn dat de input is en wat de eventuele output is.

Van Lambiek wordt goede geuze gemaakt.
bprosman

Golden Member

Over de nietszeggende variabelen ben ik het niet 100% eens

Niet alles is zwart/wit, er zijn nog minstens 50 tinten grijs.

Voor een looptellertje of een tijdelijke variabele is er niets mis mee om een X, Y oid te gebruiken, dat lees je er ook zo uit.

Voor een temperatuur inlezen oid zou ik het dan weer niet doen.

De jongere generatie loopt veel te vaak zijn PIC achterna.
Anoniem

Op 19 augustus 2019 08:51:48 schreef rew:
[...]

Het nodigt uit om commentaar/documentatie te schrijven waar je helemaal NIETS aan hebt.

Wat heb ik aan het commentaar dat dit constantes zijn? waar worden ze gebruikt? Wat heb ik aan de documentatie "Parity." bij de constante "SD_PARITY_ERROR".

Zoals voor alles geldt ook voor deze tools, "A fool with a tool is still a fool"

De door jouw aangehaalde voorbeelden zijn natuurlijk geen 'representatieve' voorbeelden voor het gebruik van commentaar.

DoxyGen heeft veel mogelijkheden om documentatie op een gestructureerde manier op de bouwen. Inclusief, functiecalls, parameter, statemachines etc.

Als je gewend bent om commentaar zoals "Dit is variabale error" zal een tool je niet verder helpen ......

Op 18 augustus 2019 20:09:27 schreef big_fat_mama:
[...]Dat maakt me benieuwd :) Maar inderdaad het is allemaal maar een kwestie van gewoontes. Zichzelf een beetje opvoeden, af en toe...

Ben te oud om heropgevoed te worden.
Hieronder een klein deeltje van mijn verzameling om aan uw nieuwsgierigheid te voldoen en het is allemaal copyright :)

Maar vergis u niet alle papiertjes zitten netjes in fardes.

LDmicro user.

Op 19 augustus 2019 09:53:27 schreef wvdakker:
DoxyGen heeft veel mogelijkheden om documentatie op een gestructureerde manier op de bouwen. Inclusief, functiecalls, parameter, statemachines etc.

Maar mijn kritiek is: "Het NODIGT UIT om nietszeggende docu te maken". En in mijn ervaring is dat 100% het geval in de projecten die doxygen gebruiken. Maar d'r zullen best tegenvoorbeelden zijn. Dat ontken ik niet. Er zullen mensen zijn die zich tegen de "uitnodiging" kunnen verzetten.

De reden is dat je de docu inline met de code schrijft. Datgene wat obvious is in het bestand met de code wordt als je het met doxygen tot losse docue maakt ineens noodzakelijk extra commentaar.

Even voor de goede orde: Ik vind doxygen een foute tool. Het resulteert in slechte docu. Dus ik gebruik het niet zelf. Ik loop er alleen tegenaan als een library of zoiets die ik wil gebruiken het gebruikt.

[Bericht gewijzigd door rew op maandag 19 augustus 2019 10:13:01 (13%)

four NANDS do make a NOR . Kijk ook eens in onze shop: http://www.bitwizard.nl/shop/

Programmeren is ook niet meteen mijn bezigheid. Met projecten waar ik aan werk hou ik een "dagboek" bij met ideeën en resultaten.

Met programmeren werk ik met modules die je in een programma kunt implementeren.
Zo had ik laatst een LCD dat zowel met een SPI als een I2C-protocol kan werken. Enkele dagen gezwoegd om het aan de praat te krijgen met een Picaxe, wat voor mij een nieuwe omgeving is. Eens de module aan het werk heb ik het begin van de module beschreven waartoe het dient en welke variabelen er worden gebruikt.
Dat deed ik ook voor een MCP23017 die ook met I2C werkt en het spaart me heel wat werk doordat ik niets meer hoef uit te pluizen en gewoon moet kopiëren.
Dat kopiëren is weliswaar zorgen dat de initialisatie en declareren van de variabelen op de juiste plaats in het programma wordt gedaan en het eigenlijk programma komt dan in een subroutine.

Depeet
Lambiek

Special Member

Op 18 augustus 2019 09:03:11 schreef MGP:
Ik schrijf per project alle denkbare gegevens op papier, krabbels, tekeningen, gebruikte formules enz.. het is een wirwar van gegevens en alles door elkaar en soms ook wel copies van aansluitgegevens ook al staan die op de computer.

Dan kunnen we elkaar de hand geven. Ik doe het op de zelfde manier, zo'n blaadje ziet er niet uit voor een ander, maar het werkt wel.

Als je haar maar goed zit, GROETEN LAMBIEK.

We zouden samen eens een halfgeleidergids moeten maken :) want jij kunt ook nog goed documenten maken en daar heb ik een hekel aan.

LDmicro user.
High met Henk

Special Member

@REW: ik liep tegen hetzelfde probleem aan: het wordt een soort pseudo code, omdat je er geen echte logica aan mee kan geven..

Het is gewoon van onder naar boven het commentaar lezen en opsommen (okee, das erg kort door de bocht, maar wel de basis)

maar het is een IDEE. Het forceert je iig wel commentaar mee te nemen (wat op zich al een goede eigenschap is)

E = MC^2, dus de magnetische compatibiliteit doet kwadratisch mee???