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%)