Ik ben dat eindeloze gedebug zat : suggesties?

[Verwijderd]

De aanleiding van dit topic is gedeeltelijk de GPC.
Ik programmeer al vele jaren maar ik krijg zelden een wat groter programma af omdat er zoveel tijd in het debuggen en het testen gaat zitten. Ik ben goed in(== vind het leuk)het bedenken van algoritmes en kan redelijk proggen. Als het bedenken van een algo 1 uur kost dan duurt bij mij het proggen 3 uur en het debuggen/testen 10 uur. Dat laatste is erg demotiverend zodat ik zelden iets af maak dus geen resultaat zie van al dat werk. En zo zit ik dus in een vicieuze cirkel. Mijn algoritmes zijn meestal vrij ingewikkeld (ongeveer niveau gpc opdracht 1) zodat de code erg onoverzichtelijk wordt. Dit probleem heb ik in alle talen die waarin ik ooit geprogd heb (basic,pascal,c++,java).
Zijn er meer mensen met dit probleem?
De meeste editors zijn niet behulpzaam in het netjes proggen en het voorkomen/opmerken van typefouten. Wat missen jullie aan de huidige editors of bestaan er wel goede?
Het verminderen van het aantal regels code zonder zoveel mogelijk op een regel te proppen zou het probleem gedeeltelijk oplossen. Dus welke statements/operatoren missen jullie in de programmeertalen?
ps dit slaat vooral op de basis van de talen dus niet de GUI/OOP onderdelen

[Verwijderd]

Wat voor type bugs heb je dan vaak ?

[Verwijderd]

Zonder gelijk lullig te doen, ligt dit volgens mij toch echt aan jou.
Als je echt een goed concept/algoritme hebt en je hebt je code overzichtelijk opgebouwd (en dat staat los van de complexiteit van de opdracht), weet je ook wanneer welke variabele welke waarde moet hebben en waar deze van waarde wijzigt. Als er dus iets fout gaat, is het als het goed is vrij snel te achterhalen welke variabele je waar in de gaten moet houden.
Zo, dit heb ik weer lekker duidelijk neergezet (NOT)

[drm]

Tja, er zijn natuurlijk 2 mogelijkheden:

1: je debugt lang omdat je algoritme zuigt
2: je debugt lang omdat je slechte code-gewoonten hebt


1
In dit geval moet je je algoritmen onderverdelen en de delen testen. Ga dan na of de tussenresultaten logischerwijs kloppen. Zo niet, verzin dan wat anders.

2
In dit geval moet je jezelf simpelweg aanleren consequent netjes te coden. Laat dit niet van een editor afhangen. Het enige wat een editor je meer biedt is syntax highlighting, en dan is het schluss. Anders word je veel te lui, en ga je vanzelf fouten maken, omdat het "toch wel verbeterd wordt door de editor".

Plus dat wanneer je fouten maakt in algoritmen, het vaak logische fouten zijn die syntactisch wel kloppen, maar logisch niet.

[Dash2in1]

Sluit me volledig aan bij drm ..
Overigens, hoe debug jij? Met scherm-/fileoutput? Of wel met een debugger?

[Verwijderd]

Op donderdag 06 december 2001 16:13 schreef Joshua30 het volgende:
Als er dus iets fout gaat, is het als het goed is vrij snel te achterhalen welke variabele je waar in de gaten moet houden.

Dit werkt normaal gesproken wel maar niet als je algo vele Kb verwerkt of duizenden mogelijkheden afgaat. Ik dan gaat het bij meestal in 1% of minder van de gevallen fout dus begin dan meer eens te zoeken.

Op donderdag 06 december 2001 16:14 schreef drm het volgende:
1: je debugt lang omdat je algoritme zuigt
2: je debugt lang omdat je slechte code-gewoonten hebt


Plus dat wanneer je fouten maakt in algoritmen, het vaak logische fouten zijn die syntactisch wel kloppen, maar logisch niet.

Het algoritme is meestal het probleem niet.
Ik code redelijk netjes en in meestal pascal zodat geen gebruik kan maken van ranzige constructie.
syntactische fouten die heb je snel opgelost. Nu de logische nog die ook veroorzaakt kunnen worden door typefouten

Op donderdag 06 december 2001 16:20 schreef Dash2in1 het volgende:
Overigens, hoe debug jij? Met scherm-/fileoutput? Of wel met een debugger?

Op beide manieren.

[Alarmnummer]

Ik gebruik zelf java, en een een stacktrace bij een prog fout helpt al enorm (en die allemaal loggen naar een file eventueel). Ik denk dat Java een taal is waar je zoveel mogelijk met het probleem oplossen bezig kan houden, ipv de problemen om het probleem op te lossen. Hierdoor ben ik niet veel tijd kwijt met debuggen.

[wasigh]

logische dingen moet je alijd testen op randvoorwaarden.
Verder wil een debugger wel eens helpen om stap voor stap door je code te lopen.

[marcelk]

Je zou natuurlijk de algoritmes formeel kunnen afleiden. Maar dan gaat er natuurlijk wel weer veel tijd in het afleiden zitten

[markvt]

als je het nu regel voor regel laat uitvoeren misschien helpt dat.

[drm]

Op donderdag 06 december 2001 16:30 schreef wasigh het volgende:
logische dingen moet je alijd testen op randvoorwaarden.
Verder wil een debugger wel eens helpen om stap voor stap door je code te lopen.

Precies.
Gewoon al je variabelen outputten op elke relevante regel code als je geen debugger ter beschikking hebt.

Maar doe dit dan wel met deelalgoritmen en niet met complexe algoritmen. Het is altijd beter om het probleem in deelproblemen te vangen.

Dat is een open deur, toch?

_{offtopic: wasigh, dat icoon kan mooier!}

[Alarmnummer]

Op donderdag 06 december 2001 16:29 schreef borganism het volgende:

[..]

Dit werkt normaal gesproken wel maar niet als je algo vele Kb verwerkt of duizenden mogelijkheden afgaat. Ik dan gaat het bij meestal in 1% of minder van de gevallen fout dus begin dan meer eens te zoeken.
[..]

Het algoritme is meestal het probleem niet.
Ik code redelijk netjes en in meestal pascal zodat geen gebruik kan maken van ranzige constructie.
syntactische fouten die heb je snel opgelost. Nu de logische nog die ook veroorzaakt kunnen worden door typefouten
[..]

Op beide manieren.

Misschien iets meer tijd steken in het ontwerpen van een algoritme? Eventueel volledig op papier uitschrijven zonder te coden zodat je echt ziet wat je doet. En zo gauw je aan symptoom bestrijding begint, stoppen en eerst nog een keer goed nadenken over je algoritme. En misschien iets beter opletten met het typen?

[Verwijderd]

Het algoritme is meestal het probleem niet.
Ik code redelijk netjes en in meestal pascal zodat geen gebruik kan maken van ranzige constructie.
syntactische fouten die heb je snel opgelost. Nu de logische nog die ook veroorzaakt kunnen worden door typefouten

WTF is dan het probleem? Typfouten 90% wordt door de compiler er uit gehaald en de rest door gewoon logisch te proggen. Als jij een variabele BLA hebt en je typt per ongeluk BLS dan ziet de compiler dat direct en krijg je een foutmelding. Het enige waar je fouten mee kunt maken als je typfouten maakt zijn reguliere expressies etc..

Als in : Misschien moet je een andere hobbie zoeken

/me code ook al wat langer en heeft een maak/debug gemiddelde van 3:1 bij complexe dingen, vooral omdat het van tevoren goed ontworpen/uitgetekend is.

[ACM]

In principe "kan" je geen bugs krijgen als je goed programmeert.

Met programmeren bedoel ik in dit geval het hele traject van vooronderzoekjes via ontwerpen tot implementeren.

Als je een goed ontwerp hebt zou de implementatie triviaal moeten zijn (alleen maar omzetten van je ideeen/pseudocode in echte code) en hoef je tijdens het implementeren alleen nog maar te denken over wat je intikt, niet waarom je wat intikt.


Helaas is dit redelijk utopisch, anders zou het allemaal wel heel makkelijk zijn

[Alarmnummer]

Op donderdag 06 december 2001 16:36 schreef Spectral het volgende:
/me code ook al wat langer en heeft een maak/debug gemiddelde van 3:1 bij complexe dingen, vooral omdat het van tevoren goed ontworpen/uitgetekend is.

Hoe hou je dat bij? Tijd noteren?

[XTerm]

Ik heb gelijkaardige problemen
Mijn code heeft de neiging weg te rotten als ik er even niet meer mee bezig ben. Dan snap ik er geen hens meer van als ik terug wil beginnen .
Is een groot nadeel uiteraard. Het helpt om zeer strict OO te programmeren en je source in zoveel mogelijk delen op te splitsen en elk deel in een apart bestand.

[wasigh]

Op donderdag 06 december 2001 16:36 schreef ACM het volgende:

Helaas is dit redelijk utopisch, anders zou het allemaal wel heel makkelijk zijn

Maak van "redelijk utopisch" maar: "iets wat bij hoge uitzondering misschien op de universiteit bij toeval gebeurd "

In het bedrijf waar ik werk is het meer:
werkt het?
mmm, het lijkt erop dat het werkt
okay dan is het goed!

[Verwijderd]

Op donderdag 06 december 2001 16:35 schreef Alarmnummer het volgende:
En misschien iets beter opletten met het typen?

Op een of andere manier als ik iets getypt heb lees ik op het beeldscherm wat ik denk dat ik getypt heb en niet wat ik werkelijk getypt heb. Dus meestal debug ik pas de volgende dag.

[drm]

Op donderdag 06 december 2001 16:41 schreef borganism het volgende:
Op een of andere manier als ik iets getypt heb lees ik op het beeldscherm wat ik denk dat ik getypt heb en niet wat ik werkelijk getypt heb. Dus meestal debug ik pas de volgende dag.

In dat geval heb je een groot probleem, en kun je inderdaad beter een andere hobby gaan zoeken (no offense)

[Alarmnummer]

Op donderdag 06 december 2001 16:41 schreef borganism het volgende:

[..]

Op een of andere manier als ik iets getypt heb lees ik op het beeldscherm wat ik denk dat ik getypt heb en niet wat ik werkelijk getypt heb. Dus meestal debug ik pas de volgende dag.

Ik gebruik zelf codeguide http://www.omnicore.com. Dit is een java editor met syntax checking. Dus onder het typen krijg je al te zien of je iets fout doet. (met klein rood streepje). Dus je hoeft al lang niet zo vaak te compileren om syntaxtische fouten eruit te halen. Blijven alleen de logische fouten over. Misschien kun je er eens naar kijken als je in Java gaat proggen. (IDEA van http://intellij.com die kan het ook een beetje).

[BierPul]

je kan natuurlijk ook gaan timmeren ofzow ben je gelijk van het gezeik af

[wasigh]

typefouten zijn het probleem niet aangezien je compiler die er wel uit filterd.

Maar logische fouten, een lus die een keer teveel of te weinig loopt. Tja dat is echt alleen met testen & debuggen op te lossen.

[Alarmnummer]

Op donderdag 06 december 2001 16:47 schreef wasigh het volgende:
typefouten zijn het probleem niet aangezien je compiler die er wel uit filterd.

Maar logische fouten, een lus die een keer teveel of te weinig loopt. Tja dat is echt alleen met testen & debuggen op te lossen.

Ik heb niet vaak een eindeloos lus probleem of index out of bounds problemen. Voornamelijk omdat ik altijd dezelfde while en for constructies gebruikt. Zorgen dat je 'standaard' code maakt scheelt al heel veel ellende.

[PipoDeClown]

---
Wie zei ook alweer dat coden 1% inspiratie en 99% transpiratie is?
---

[Tsjipmanz]

Een ingewikkeld algoritme hoeft niet per definitie complexe code op te leveren. Ik denk dat je dan toch de hand in eigen boezem moet steken. Aan de andere kant, je wekt wel de indruk plezier te hebben in het programmeren op zich.
Probeer dus toch maar zo gestructureerd mogelijk te werken, deel je programma zoveel mogelijk op in functionele, hapklare brokken, geef logische variabelenamen en gebruik duidelijk commentaar. Op deze manier is de debugtijd te minimaliseren.

Denk ook vantevoren na welke problemen zouden kunnen optreden bij een bepaalde implementatie, en maak gebruik van incremental delivery. Vooral bij grotere projecten is dit een aanrader. Als je niet weet wat dit inhoudt: ID is dat je uitgaat van een bepaalde basisfunctionaliteit, en dit stapje voor stapje gaat implementeren, testen en weer verder uitbreiden. Dit zorgt ervoor dat je eventuele "beren op de weg" snel tegenkomt, en derhalve ook veel beter de oorsprong en de locatie van de fout kan traceren. Dit vergt natuurlijk wel wat nadenkwerk van tevoren, zoals anderen hier al zeggen. Je hoort het: een goed ontwerp is onvermijdelijk.

Suv6 ermee in elk geval

[Verwijderd]

Op donderdag 06 december 2001 16:47 schreef wasigh het volgende:
typefouten zijn het probleem niet aangezien je compiler die er wel uit filterd.

Maar logische fouten, een lus die een keer teveel of te weinig loopt. Tja dat is echt alleen met testen & debuggen op te lossen.

typefouten in ruime zin wel, ik spring in mijn gedachten wel eens onbewust naar een volgende regel zodat het resultaat een gemixte regel is of een overgslagen regel wat weer de meest vreemde logische fouten geeft. Helaas heb ik dit ook met gewone taal

[drm]

Op donderdag 06 december 2001 16:47 schreef wasigh het volgende:
typefouten zijn het probleem niet aangezien je compiler die er wel uit filterd t.

mwah...

code:

if ( sjaak & bever ) // of moest daar && staan :?
{
   // ...
}

kan er nog wel een paar verzinnen

[Alarmnummer]

klassieke pascal fout

code:

if a>40 and b>30 then begin
....

is:

if a>(40 and b)>30 then begin
....

had moeten zijn:
if (a>40) and (b>30) then begin

[Dash2in1]

Op donderdag 06 december 2001 16:55 schreef drm het volgende:

[..]

mwah...

code:

if ( sjaak & bever ) // of moest daar && staan :?
{
   // ...
}

kan er nog wel een paar verzinnen

[off-topic]
Wat maakt het feitelijk uit of je in dat geval & of && gebruikt .. feitelijk krijg je nogsteeds wel true (in c bv)?! Overigens doe ik gewoon && hoor
[/off-topic]

[wasigh]

Op donderdag 06 december 2001 17:01 schreef Dash2in1 het volgende:

[..]

[off-topic]
Wat maakt het feitelijk uit of je in dat geval & of && gebruikt .. feitelijk krijg je nogsteeds wel true (in c bv)?! Overigens doe ik gewoon && hoor
[/off-topic]

&& is shortcut operator,
als na de eerste blijkt dat de uitkomst al vast staat wordt de 2e niet meer uitgvoerd. Kan best makkelijk zijn:

code:

if (object != null && object.length() > 0)

[Alarmnummer]

Op donderdag 06 december 2001 17:01 schreef Dash2in1 het volgende:

[..]

[off-topic]
Wat maakt het feitelijk uit of je in dat geval & of && gebruikt .. feitelijk krijg je nogsteeds wel true (in c bv)?! Overigens doe ik gewoon && hoor
[/off-topic]

Dat is juist het probleem. Je ziet niet eens dat je iets fout doet, en daardoor lees je er ook heel makkelijk over.

vb.

int a = eenfunctie; //nu staat adres van functie in a
ipv
int a = eenfunctie();

(dit is voorbeeld van tc 2.0 waar je echt overheen kijkt (ik wel )).

[drm]

Op donderdag 06 december 2001 17:01 schreef Dash2in1 het volgende:

[..]

[off-topic]
Wat maakt het feitelijk uit of je in dat geval & of && gebruikt .. feitelijk krijg je nogsteeds wel true (in c bv)?! Overigens doe ik gewoon && hoor
[/off-topic]

Nee. Want & is een bitwise operator, en daarbij stelt ( a & b) dus 1 expressie voor, en (a && b) 2 expressies die beiden waar moeten zijn.

[Alarmnummer]

Op donderdag 06 december 2001 17:07 schreef drm het volgende:

[..]

Nee. Want & is een bitwise operator, en daarbij stelt ( a & b) dus 1 expressie voor, en (a && b) 2 expressies die beiden waar moeten zijn.

het ligt eraan in welke taal je werkt. In C zal het geen parse problemen opleveren, in java gelukkig wel. (Gebruik van & ipv && )

[Bobco]

Wat in dit soort gevallen misschien nog kan helpen is je code/test/debug cycle zo kort mogelijk houden. Ga geen lange lappen code schrijven en dan eindeloos testen en debuggen, maar schrijf kleine stukjes en test meteen of die het goed doen.

De juiste hulpmiddelen willen natuurlijk ook wel helpen. Waarden van variabelen printen is een techniek die ik alleen gebruik als ik niks anders bij de hand heb.

[drm]

Op donderdag 06 december 2001 17:12 schreef Alarmnummer het volgende:
het ligt eraan in welke taal je werkt. In C zal het geen parse problemen opleveren, in java gelukkig wel. (Gebruik van & ipv && )

Komt omdat de typechecking van Java een stuk verder gevorderd is dan in C. Ook dan de wat oudere versies van C++.

Ook gebruik van haakjes is heel belangrijk. Als je daar tikfouten in maakt gaat vaak de volledige logische betekenis van de expressie onderuit.

[Alarmnummer]

Op donderdag 06 december 2001 17:32 schreef drm het volgende:

[..]

Komt omdat de typechecking van Java een stuk verder gevorderd is dan in C. Ook dan de wat oudere versies van C++.

Ook gebruik van haakjes is heel belangrijk. Als je daar tikfouten in maakt gaat vaak de volledige logische betekenis van de expressie onderuit.

het komt ook omdat c geen boolean type heeft, maar werkt met een int(, char etc). dus if(10)... is syntactisch correct. (ik praat nog over oude c weet niet hoe het tegenwoordig is).