Vraagje aan de professionele/ervaren programmeurs

[Verwijderd]

Ik ben op het moment veel bezig met programmeren...als hobby, maar ook voor mijn opleiding (laatste half jaar...en dat is een stageperiode wat uitstekend bevalt). Ik heb behoorlijk wat ervaring met ASP (en HTML, CSS, SQL) en heb 2 jaar geleden redelijk wat opgestoken van C++. Nou ben ik dus bezig met C++ Builder wat op zich aardig opschiet, maar ik merk dat mijn manier van programmeren niet de beste is. Waarom? Omdat veel problemen waar ik tegenaan loop, voornamelijk komen door het feit dat de structuur van mijn source op een gegeven moment nogal rommelig wordt en ik zelf regelmatig loop te puzzelen over waarom ik een bepaalde functie op die manier heb gemaakt. Ik denk dat het voor mij belangrijk is dat ik daar eerst eens wat aan probeer te doen.

Nou, mijn vraag aan de meer ervaren programmeurs onder jullie: Hoe pak je het maken van een programma nou aan?
Zorg dat je een gedetaileerde structuur op papier hebt van datgene wat je gaat maken? Zo ja, hoe bouw je die op (voorbeeldje misschien)?
Wat voor namen geef je aan variabelen zodat je later ook nog weet waarvoor ze dienen?
Wat beschrijf je in het commentaar?
Wanneer begin je een gedeelte uitgebreid te testen en zorg je dat eerst ieder onderdeeltje nagenoeg foutloos is (ik bedoel niet de compiler en/of runtime errors maar of het datgene doet wat het zou moeten doen) voor je verder gaat of komt dat pas na een hele berg code?

Kortom...geef mij wat tips en to-do's/not-to's aub. Waar moet ik op letten bij het maken van een programma?

[CyBeR]

Ik ben dan wel geen ervaren of professionele programmeur, maar ik vind het wel handig om van tevoren te bedenken wat je wilt, en hoe je het wilt. Schrijf dat ook ergens op, zodat je het later kunt raadplegen en je niet steeds nieuwe manieren bedenkt die niet goed samenwerken met wat je al had.

Waarom vraag je dit soort dingen ook op dit soort tijden trouwens?
ok, de meest briljante code wordt 's ochtends vroeg geschreven, maar forumposten valt daar niet onder

[Verwijderd]

Zoals ik het (heb geleerd) is eerst een analyse maken. Dus bv in onderdelen opschrijven wat het moet kunnen(nog geen code). Dan stap voor stap uitwerken hoe welk onderdeel werkt. Als je een goed beeld hebt welke onderdelen je moet hebben, bv file access en/of database connecties etc, dan kan je opzich bezich gaan met het kloppen.
Wel is handig om het user interface niet te intergreren met het eigenlijkwe programma.
Een soort interface is hierbij handig. Dit is dus een class die communicatie tussen user interface en het eigenlijke programma mogelijk maakt.
Ook gestructureerde notaties van methoden en variabelen maakt het nalezen een stuk gezelliger.

[Verwijderd]

[b]Op woensdag 20 februari 2002 02:36 schreef CyBeR
Waarom vraag je dit soort dingen ook op dit soort tijden trouwens?
ok, de meest briljante code wordt 's ochtends vroeg geschreven, maar forumposten valt daar niet onder

Hoezow? Zulke tijden? Om 4 uur lig ik er nooit in. Nu is het lekker rustig in huis, en gaat internetten heerlijk.
En inderdaad 's avonds(jij noemt dat 's ochtends) komt de code er stukken beter en sneller uit.

[Scorpion]

om rommelige code te voorkomen moet je een goed ontwerp hebben. als je die goed hebt gemaakt, dan is het ook een stuk duidelijker hoe het programma in elkaar zit.

verder kan je eens kijken naar de hongarian notatie voor c/c++. dit is een simpele manier van variabel-namen/etc.. gebruiken. c# adviseert ms om pascal-notatie (correct me if i'm wrong) te gebruiken. meende hier een topic voorbij zien komen die hier over ging). zo is het ook meteen een stuk duidelijker, kan je meteen zien watvoor type de variabele is etc... anyway ik denk dat je de point wel get.

[markvt]

schema's tekenen van te voren en de programmaloop op papier zetten.

PSD & PSS maken dus.

[Slagroom]

Op woensdag 20 februari 2002 08:25 schreef markvt het volgende:
schema's tekenen van te voren en de programmaloop op papier zetten.

PSD & PSS maken dus.

Wil je zeggen dat jij voor dikke lappen code een PSDtje gaat maken?

[ACM]

Op woensdag 20 februari 2002 09:16 schreef Monstar.nl het volgende:
Wil je zeggen dat jij voor dikke lappen code een PSDtje gaat maken?

Juist voor grote lappen code kan je imho beter wel schema's maken.

Wat voor schematisch ontwerp je wilt maken moet je zelf weten, maar hoe groter de te ontwikkelen projecten hoe belangrijker een uitgebreid ontwerp is.
[edit]
En daarbij komt dat je bijna altijd de code kan splitsen in kleinere lappen en daar de gedetaileerdere schema's voor kan maken.

[Nitroglycerine]

aan de hand van het technisch ontwerp - wat vaak al een vrij gedetailleerd beeld geeft van hetgeen verwacht wordt - deel je je programma in in onderdelen / functies, wat je op papier uittekent. Het kunnen zien is een heel handig middel om complexe programma's te maken

[Verwijderd]

Een goed functioneel ontwerp (of functioneel detail ontwerp) is het belangrijkste. De code wordt toch vaak enigszins een rommeltje, zeker met 4gl talen. Zet veel commentaar rond je code, heb je meer aan dan alles op papier waar je elke keer naar moet zoeken.

[Janoz]

Goed commentaar.

Zet bij je functies/procedures/methoden de pre en post condities neer. Geef daarbij ook duidelijk de randvoorwaarden aan. Als je in een methode bijvoorbeeld geen boundschecking doet, geef dit dan ook aan in je commentaar zodat je bij een aanroep weet dat je ervoor moet zorgen dat je niet buiten die bounds komt

Maak weinig tot geen gebruik van globale variabelen.

Korte var en functienamen lijken mischien minder type werk, maar maken je source niet duidelijker. Het is helemaal niet erg om een var met de naam 'paginaTotaal' te hebben ipv 'pt'.

Werk aan kleine stukjes per keer, en ga niet tijdens het proggen nieuwe functionaliteit verzinnen.

[Verwijderd]

Hoewel het op school allemaal goed geleerd is (PSD's) zul je deze in de praktijk bijna niet tegenkomen. Een goed haalbaarheidsonderzoek vooraf, vervolgens een Functioneel ontwerp en daarna een technisch ontwerp werkt imho sneller. Wel is het handig om kleine stukjes te documenteren (bijv. bij een functie even kort toelichten wat er gebeurd).

Rommelige code heeft volgens mij niet alles te maken met een goed vooropgezet schema. Ik kan bijvoorbeeld prachtige code schrijven die voor geen hol doet wat er in mijn schema stond. Ook andersom geld hetzelfde: rommelige code die precies doet wat er in het schema staat.

[Skinkie]

Het ligt er helemaal aan wat voor denker jij bent... ben je een beelddenker dan wil je, je progie gevisualiseerd zien (dan bedoel ik de code dus).

Zelf trek ik altijd een oudpapier a4tje uit de printer en leg um in de breedte neer en ga ff aangeven wat het nou gaat worden allemaal wat voor relaties alles met elkaar heeft... een paar kleine regeltjes code er tussen en je hebt een aantal deelproblemen die veel makkelijker oplosbaar zijn dan een groot probleem.

Zelf ben ik zo'n programmeur van: Follow your heart and your API. Dus ik ga me ook echt niet toeleggen op een speciefieke taal. Als allround programmeur kun je in alle talen programmeren als je weet hoe een programmeer taal werkt en dat is natuurlijk allemaal uitebreid gedocumenteerd... dus waarom zou je het allemaal zelf gaan onthouden

Ik ben nu bezig met heel veel verschillende dingen, maar echt nieuwe dingen heb ik toch wel binnen twee weken (spare time) onder de knie.

Dus ga de structuur verbeteren door van te voren je einddoel te bepalen.

[Alarmnummer]

Op woensdag 20 februari 2002 01:29 schreef D-mension het volgende:
Ik ben op het moment veel bezig met programmeren...als hobby, maar ook voor mijn opleiding (laatste half jaar...en dat is een stageperiode wat uitstekend bevalt). Ik heb behoorlijk wat ervaring met ASP (en HTML, CSS, SQL) en heb 2 jaar geleden redelijk wat opgestoken van C++. Nou ben ik dus bezig met C++ Builder wat op zich aardig opschiet, maar ik merk dat mijn manier van programmeren niet de beste is. Waarom? Omdat veel problemen waar ik tegenaan loop, voornamelijk komen door het feit dat de structuur van mijn source op een gegeven moment nogal rommelig wordt en ik zelf regelmatig loop te puzzelen over waarom ik een bepaalde functie op die manier heb gemaakt.

Probeer je methodes/functies niet te lang te maken zodat je in een paar seconden kan zien wat er gebeurd. Probeer de methodes ook te documenteren of van een dusdanig goeie naam te voorzien dat je er mee uti de voeten kan (documentatie is een stuk beter trouwens). Als ik een langere procedure heb dan bouw ik kleine eilandjes met bij elkaar horende code op met 1 regel commentaar zodat ik alleen het commentaar hoef te lezen om te begrijpen wat er gebeurd.

En na een tijdje zal je programma door evolutie gaan veranderen. Ik besteed daarom ook wat tijd (vooral als ik geen zin heb om echt denk werk te verrichten) een het opschonen van code. Hierdoor blijft code bij mij altijd schoon en heb geen (lees niet vaak) last van: 'waar is dit nog maar goed voor?' code.

Ik denk dat het voor mij belangrijk is dat ik daar eerst eens wat aan probeer te doen.

wijs

Nou, mijn vraag aan de meer ervaren programmeurs onder jullie: Hoe pak je het maken van een programma nou aan?
Zorg dat je een gedetaileerde structuur op papier hebt van datgene wat je gaat maken? Zo ja, hoe bouw je die op (voorbeeldje misschien)?

Alleen lastige dingen werk ik eerst op papier uit, maar het meeste doe ik on the fly. Jaja.. ik weet het. Het is niet de beste methode maar in de toekomst ga ik meer met UML werken.

Wat voor namen geef je aan variabelen zodat je later ook nog weet waarvoor ze dienen?

Ik gebruik vaste index variable namen: k,l,i en verder hergebruik ik ook nooit variablen. Dit is misschien wel wat langzamer omdat je meer variablen aanmaakt. Maar het maakt de code wel zo leesbaar. En ik geef ze altijd een duidelijke naam die soms wat lang is. bv
totaalKosten maxAantalPersoon

Wat beschrijf je in het commentaar?

een groot deel van het commentaar schrijf ik als ik een classe aan het opschonen ben. Om klaar te maken voor serieus gebruik. In het begin is de structuur vaak nog een keer aan het veranderen en vind het dan zonde om overal nette commentaar bij te zetten.

Wanneer begin je een gedeelte uitgebreid te testen en zorg je dat eerst ieder onderdeeltje nagenoeg foutloos is (ik bedoel niet de compiler en/of runtime errors maar of het datgene doet wat het zou moeten doen) voor je verder gaat of komt dat pas na een hele berg code?

Je hebt hier een bepaalde 'techniek' voor: unit test. Hierdoor kun je heel eenvoudig objecten doormeten zonder eerst je programma op te starten. Wat je in wezen doet is een mini programma maken en daarin even de net gemaakte objecten inzetten en dan jouw methodes er even oplos laten zodat je kan zien dat ze het goed doen.

Een andere manier om je code wat robuster te maken is door extra checks erin te zetten. Bij iedere methode die ik maak worden de argumenten gechecked op null of op toegestane waarden. Hierdoor krijg ik meteen een foutmelding als ik een prog fout heb gemaakt ipv het pas later (of nooit) te voor schijn komt. Dit heet dan ook wel met een mooi woord: pre condities.

Kortom...geef mij wat tips en to-do's/not-to's aub. Waar moet ik op letten bij het maken van een programma?

Ik hoop dat ik je een paar tips heb gegeven waarmee je uit de voeten kan. PS ik ben een java programmeur en ik heb de indruk dat er aan de java kant veel meer standaarden zijn dan in de c(++) wereld. Hierdoor krijg je ook veel strakkere code omdat veel problemen zijn uitgewerkt. Een van de dingen die ik zelf erg fijn vind is extra duidelijke namen voro statische en member variablen (variablen van het object). Een statische variable krijg een '_' ervoor, dus _maxGewicht en een member variable krijgt een 'm_' ervoor dus m_leeftijd. Hierdoor maak ik ook minder fouten en begrijp sneller wat voor een soort type een variable is. Oja.. een van mijn oudere maar nog steeds gewardeerde naamgevings technieken is het type van een variable achter de variable te zetten, dus janPersoon of okButton. Hierdoor zie je een stuk sneller wat voor object je te pakken hebt.

[Alarmnummer]

oja... het wil ook erg helpen om variablen te declareren op het moment dat je ze nodig bent.

dus bv:

code:

Persoon tempPersoon = null;
for(int k=0;k<size;k++){
   tempPersoon = persoonList.get(k);
   ...
}

[Verwijderd]

Een boek kan meestal ook helpen. En dan bedoel ik niet een boek zoals CoreJava, maar het leren goed programmeren.
Code overtypen kan iedereen. Wij gebruiken op school oa "Leren programmeren in 48 uur". Nu doen wij dit niet in 48 uur, maar het idee is hetzelfde.

[metaal]

Voor je een programma gaat schrijven dat waarschijnlijk groter wordt dat 500 lines, is het misschien handig een ontwerp te maken in UML. UML is een "taal" in de vorm van diagrammen. Belangrijkste diagrammen zijn een klassediagram en een sequencediagram (geeft aan hoe objecten met elkaar communiceren).

Als je een programma zoekt om die diagrammen in te tekenen: Together is misschien handig.

[Alarmnummer]

ik denk niet alleen een goed leer boek voldoende is omdat de voorbeelden altijd erg klein zijn en ze alleen zijn bedoeld om uitleg te geven over een bepaald probleem. Je leert hiermee wel allerlei technieken maar heel weinig:' hoe gaat het dan in het echt?' Vooral problemen die optreden door evolutie en grote classes worden altijd vermeden omdat alle voorbeelden altijd in 1 keer goed gaan.

[koffercomputer]

Goede code is IMHO elegant, geen knutsel oplossingen, en mooie loops en condities. Als je op die manier kunt programmeren, dan zal je code echt geen rommeltje worden.

Natuurlijk begin je met het opdelen van het hoofdprobleem in kleinere probleempjes, welke je daarna weer opdeelt in nog kleinere probleempjes. Op die manier kun je steeds aan een heel klein stukje werken zonder dat je het overzicht kwijtraakt.

Een goed ontwerp is onmisbaar bij het schrijven van grote programma's.

[MSalters]

Dit is een vrij standaard probleem; "The Practice of Programming" van Kernighan & Pike gaat dieper in op alles wat om programmeren heen gebeurt.

Wat design betreft: IHA begin je met met 1 of meer requirements. Als je die in <10 regels code kunt implementeren, dan doe je dat direct. Als je 10 tot 100 regels code nodig hebt, dan maak je een design document. Dit breekt de requirements op in stukken die <10 regels code nodig hebben.
Als je 100 tot 1000 regels code per requirement nodig gaat hebben, dan implementeer je een High-Level design en een Low-level design, met twee niveaus van opsplitsing.
Als je meer dan 1000 regels code per requirement hebt moet je gaan nadenken over een gestructureerde approach, en ervaren architecten erbij gaan trekken. Maar als je dit soort vragen nog hebt, dan zou je dit soort requirements niet moeten tegenkomen.

[whoami]

Een goed programma begint bij een goede analyse. En die analyse bestaat uit verschillende onderdelen:

* Definitie-studie
Waarvoor dient het programma? Wat moet het kunnen? Welke mensen gaan er mee werken...

* Functioneel ontwerp
Hier ga je uw datamodel gaan ontwerpen, ga je de verschillende onderdelen/modules van het programma gaan bepalen enz.
Hier kan je ook bepalen welke classes je gaat definieren en hoe die classes met elkaar in relatie staan.

* Technisch ontwerp
Aan welke systeemeisen moet het programma voldoen.
Bepalen welke ontwikkeltools je gaat gebruiken, welk DBMS enzo je gaat gaan gebruiken.
Hier kun je ook de schermen ontwerpen.

* Programmatie
De specificaties die je gemaakt hebt in de voorgaande fases ga je nu gaan omzetten naar code.
Bij het coderen van uw programma moet je voldoende commentaar gebruiken, maar zorg er wel voor dat uw commentaar niet nutteloos is.
Ga dus ook niet gaan overdrijven met het commentarieren. Bij een complex stuk code kun je in uw commentaar gaan schrijven wat die code precies doet. Het kan ook nuttig zijn om commentaar te schrijven bij de declaratie van variablen (voor wat wordt de var gebruikt?).
Pas bij het programmeren ook een consistente lay-out toe. (Er is hier al eens een topic over geweest, en het is nu terug te vinden bij de 'sticky-topics'). Wat je bv kunt doen is je code uitlijnen:

code:

 NaamLabel.Text     := 'Hier komt de naam';
 AdresLabel.Text    := 'Adres';
 GemeenteLabel.Text := 'Gemeente';

Gebruik ook duidelijke namen voor je variablen en declareer al je variablen op een centrale plaats, het begin van een functie.


Zo, even summier mijn manier neergepend. Ik kon nog wel wat uitgebreider zijn, maar ik ben een beetje lui vandaag.

[Verwijderd]

Ok, mensen...hartstikke bedankt. Hier kan ik tenminste wat mee ...vooral het opdelen van code in kleinere (deel)functies lijkt me idd wel een verstandige werkwijze...ik zit nou nog regelmatig met 8 beeldschermen lange code waarin 20 "for" en "while" lussen verwerkt zitten te klooien. Dat moet ik toch eens zien te voorkomen.
Enne...ik heb op school ook met Flowcharts gewerkt (SDW) maar ik vind het op het moment nog erg lastig om een nuttige structuur neer te zetten. Maar goed...dat komt wel. Misschien ff wat minder hoge eisen stellen aan datgene wat ik wil maken en zorgen dat de opbouw en structuur van mijn code verbeteren. Alles komt goed...

-greetingz

[Verwijderd]

Oh ja...btw: weet er toevallig iemand een goed boek over C++ builder?

[Alarmnummer]

[b]Op woensdag 20 februari 2002 19:45 schreef D-ik zit nou nog regelmatig met 8 beeldschermen lange code waarin 20 "for" en "while" lussen verwerkt zitten te klooien. Dat moet ik toch eens zien te voorkomen.

Dat lijkt me wel vrij handig ja

[^Mo^]

Op woensdag 20 februari 2002 11:15 schreef Alarmnummer het volgende:
oja... het wil ook erg helpen om variablen te declareren op het moment dat je ze nodig bent.

dus bv:

code:

Persoon tempPersoon = null;
for(int k=0;k<size;k++){
   tempPersoon = persoonList.get(k);
   ...
}

is een beetje discutabel in dit geval aangezien de scope van k zich niet meer beperkt tot alleen de for-loop (tenminste niet met nieuwe compilers). Of je gebruikt dit en daarna nooit meer (binnen dezelfde scope) k gebruiken.. persoonlijk declareer ik een tellertje aan het begin van de scope ..

[Alarmnummer]

Op woensdag 20 februari 2002 19:58 schreef _Mo_ het volgende:

[..]

is een beetje discutabel in dit geval aangezien de scope van k zich niet meer beperkt tot alleen de for-loop (tenminste niet met nieuwe compilers). Of je gebruikt dit en daarna nooit meer (binnen dezelfde scope) k gebruiken.. persoonlijk declareer ik een tellertje aan het begin van de scope ..

Ik weet niet over welke taal je het hebt, maar bij java is de scoop van k toch echt alleen in de for lus. (heb het net ff gechecked voor de zekerheid).

[Orphix]

Op woensdag 20 februari 2002 20:00 schreef Alarmnummer het volgende:

[..]

Ik weet niet over welke taal je het hebt, maar bij java is de scoop van k toch echt alleen in de for lus. (heb het net ff gechecked voor de zekerheid).

Ik geloof dat het in C/C++ officieel ook zo is (dus is k alleen in de lus in scope). Maar de Visual C++ compiler doet dit dus niet....

[^Mo^]

Op woensdag 20 februari 2002 20:00 schreef Alarmnummer het volgende:

[..]

Ik weet niet over welke taal je het hebt, maar bij java is de scoop van k toch echt alleen in de for lus. (heb het net ff gechecked voor de zekerheid).

sorry, 'tis zo in C++. Het was inderdaad met C++ zo dat een declaratie van een variabele in een for-loop een beperkte scope had. Dit is echter niet meer de standaard en geldt de scope van k voor de gehele functie.
ff linkje opgezocht: http://www.mvps.org/vcfaq/lang/1.htm

[RickN]

Op woensdag 20 februari 2002 19:58 schreef _Mo_ het volgende:

[..]

(tenminste niet met nieuwe compilers).
[..]

Ik denk dat je bedoelt: non-ANSI compliant compilers....

Ik kwam er idd achter dat de VC++ compiler de variable buiten de scope van de for loop laat bestaan, maar dat slaat natuurlijk nergens op. Dat ding moet gewoon een lokale variable zijn, en dat is het (laatste keer dat ik checkte) in g++ ook.

[RickN]

Op woensdag 20 februari 2002 20:19 schreef _Mo_ het volgende:

[..]

http://www.mvps.org/vcfaq/lang/1.htm

Euhm, tenzij m'n engels recentelijk flink achteruit is gegaan zegt deze link toch juist dat het de standaard is om de variable alleen BINNEN de for loop te laten bestaan.

Voor compatibiliteit heeft Microsoft wat workarounds bedacht, om code die op de oude (verkeerde) manier is geschreven niet van kant te maken.

[The - DDD]

Belangrijkste om betrekkelijk eenvoudig je functies en dergelijke terug te vinden is om alles goed onder te brengen in modules.

Functies met betrekking tot de groeisnelheid van een grassprietje in je grasmat simulatie pakket? Allemaal in een eigen moduele. Zo hou je een beperkt aantal functies per source, dit heeft tot gevolg dat je eenvoudiger iets terug kan vinden. Iets gerelateerd aan grasgroeisnelheid, nou dat zal vast in de module "grasgroeifuncs" staan.

Verder is overstappen op OO misschien een idee. Als dat paradigma je goed bevalt, dan ben je vanzelf meer geneigd om alles netjes onder te verdelen in aparte files. Nadeel van OO is meestal het aantal verscillende files waar je programma uit bestaat. Meestal iets meer dan een vergelijkbaar procedureel programma. Alhoewel de daadwerkelijke sourcecode hoeveelheid meestal iets minder is.


Ook een duidelijke uniforme code opmaak is van belang.
En vergeet het belang van goede documentatie niet. Zowel commentaar als in aparte docs.

[farlane]

Wat ik erg goed vind werken (als je geen week wilt documenteren voordat je begint met coden ) is goed nadenken over de interfaces van je functies. In C/C++ houdt dat dus in dat je eerst je header files maakt voordat je de functies/classes/whatever zelf gaat implementeren.

Op die manier wordt je gedwongen om na te denken over de structuur van je progje, en de structuur van je modules ("Hoort dit misschien in een andere header ?") terwijl je toch het idee hebt dat je aan het coden bent. ( Typen iig )

Grotere projecten hebben op den duur veel voordeel van documentatie, het liefst in de source code want daar wordt het meest naar gekeken.

En natuurlijk..... geen goto, in geen enkele taal. (Dus ook niet in VB)

[whoami]

Op donderdag 21 februari 2002 10:14 schreef farlane het volgende:
Grotere projecten hebben op den duur veel voordeel van documentatie, het liefst in de source code want daar wordt het meest naar gekeken.

Als ik moet beginnen met een bestaand programma aan te passen, dan ga ik niet gelijk de code induiken, maar ga ik toch eerst even wat analyses en technische info doorlezen. In uw code moet er commentaar staan, maar er mag daar niet in overdreven worden.

[farlane]

Op donderdag 21 februari 2002 12:03 schreef whoami het volgende:
[..]
In uw code moet er commentaar staan, maar er mag daar niet in overdreven worden.

Hmmm.. overdreven veel commentaar is over het algemeen slecht commentaar. Dan kun je idd beter geen commentaar hebben.

Als je structurele aanpassingen gaat maken is het wellicht noodzakelijk/handig om de ontwerp documenten erbij te hebben. In het geval van bughunten of kleine aanpassingen vind ik het niet echt nodig om die docs allemaal door te gaan lezen. Commentaar bij de code vind ik dan onmisbaar..

[Stephan Oudmaijer]

Op woensdag 20 februari 2002 09:20 schreef ACM het volgende:

[..]

Juist voor grote lappen code kan je imho beter wel schema's maken.

Wat voor schematisch ontwerp je wilt maken moet je zelf weten, maar hoe groter de te ontwikkelen projecten hoe belangrijker een uitgebreid ontwerp is.
[edit]
En daarbij komt dat je bijna altijd de code kan splitsen in kleinere lappen en daar de gedetaileerdere schema's voor kan maken.

psd`s zijn oud, maak uml schema`s oid. moet je wel uml kennen.

en een tip voor de topic starter, lees eens wat info over object georienteerd programmeren, meer heb je niet nodig.