[Alg] Hoeveel rekening houden met debuggen tijdens coden?

[MrBucket]

Ik vond mezelf weer bezig met het toevoegen van extra member functies aan mijn classes die geen ander doel dienen dan het debuggen van mijn programma te vergemakkelijken, en toen vroeg ik mij af:

In hoeverre houden jullie tijdens het coden van een programma rekening met de "debugability" ervan?

Schrijven jullie voor complexe classes bijvoorbeeld standaard een toString() / std::ostream &operator<<(), om later de inhoud ervan te kunnen bekijken (of voeg je die later toe tijdens het debug-proces, en laat je het in de productie-code staan)?

Gebruiken jullie tijdelijke variabelen om een resultaat van een berekening of functie in op te slaan (terwijl je de uitkomst ook rechtstreeks zou kunnen gebruiken), puur om de waarde ervan tijdens het debuggen makkelijk te kunnen bekijken?

Zijn er uberhaupt zaken in jullie programma's die er alleen in staan om het debuggen te vergemakkelijken? Hoever gaan jullie hierin?

Ben wel benieuwd hoe anderen hiermee omgaan

[Verwijderd]

Ik bouw websites, zoals bij elk ander stukje software is testen en debuggen is uiteraard zeer belangrijk. Maar bij het testen van mijn eigen gebouwde applicatie komen waarschijnlijk nooit alle fouten naar boven die gebruikers kunnen maken. Ik vind het daarom dus zeer belangrijk dat ik weer wanneer het fout gaat in de live omgeving van de website. Ik heb hiervoor een error handler geschreven. De bezoekers van de site krijgt een nette foutmelding te zien, maar op de achtergrond wordt de foutmelding, het bestand waar het fout ging, het regelnummer, de informatie uit de sessie, cookie, get, post en de server variabelen naar mij toe ge-emaild. Hierdoor kan ik op eenvoudige wijze het probleem reproduceren en oplossen.

[whoami]

MrBucket schreef op maandag 14 maart 2005 @ 22:58:
Schrijven jullie voor complexe classes bijvoorbeeld standaard een toString() / std::ostream &operator<<(), om later de inhoud ervan te kunnen bekijken (of voeg je die later toe tijdens het debug-proces, en laat je het in de productie-code staan)?

Nee; een beetje IDE biedt toch wel de mogelijkheid om 'watches' te gebruiken waarmee je de inhoud van variablen kunt zien.
Dat, en het command window in VS.NET zijn 2 -voor mij- belangrijke hulpmiddelen bij het debuggen.

Debug-code laat ik vrijwel nooit in m'n code staan; al kan je bij mij soms hier en daar nog wel

code:

System.Diagnostics.Debug.WriteLine (...)

regels vinden. Echter, deze worden bij een release build toch niet meegecompiled.

[HunterPro]

inderdaad op runtime variables uitlezen met je ide, en soms wat tijdelijke vars inbouwen. Maar die plaats ik altijd náást m'n werkelijke acties - tijdelijke vars zijn namelijk niet nodig voor de applicatie en daarmee is het codevervuiling die gewoon verwijderd moet worden. Met andere woorden: zodra de code in productie gaat gaan die dingen eruit

* HunterPro is voor compacte productiecode

[ Voor 13% gewijzigd door HunterPro op 15-03-2005 08:55 ]

[Bobco]

Zelf gebruik ik graag een logging toolkit waarbij je kunt instellen wat er precies gelogd wordt. Voor mij is dat voor Java Log4J (ook verkrijgbaar in smaken voor C++ en C#, dacht ik). Door simpelweg een configuratiefile aan te passen schakel ik in 1 keer van logging op INFO nivo naar logging op DEBUG nivo. De applicatiecode blijft dan precies hetzelfde. Uiteraard kost dit wel wat performance omdat Log4J runtime vast moet stellen of een bepaald log statement wel of niet tot output moet leiden, maar dat is bijna te verwaarlozen.

[Verwijderd]

Verwijderd schreef op dinsdag 15 maart 2005 @ 00:17:
Ik bouw websites, zoals bij elk ander stukje software is testen en debuggen is uiteraard zeer belangrijk. Maar bij het testen van mijn eigen gebouwde applicatie komen waarschijnlijk nooit alle fouten naar boven die gebruikers kunnen maken. Ik vind het daarom dus zeer belangrijk dat ik weer wanneer het fout gaat in de live omgeving van de website. Ik heb hiervoor een error handler geschreven. De bezoekers van de site krijgt een nette foutmelding te zien, maar op de achtergrond wordt de foutmelding, het bestand waar het fout ging, het regelnummer, de informatie uit de sessie, cookie, get, post en de server variabelen naar mij toe ge-emaild. Hierdoor kan ik op eenvoudige wijze het probleem reproduceren en oplossen.

Hoe onderdruk je de foutmelding die atm aanwezig is dan? Ik snap wel dat dat kan met de @ operator alleen om dat nu bij elke functie te doen?

[MrBucket]

whoami schreef op dinsdag 15 maart 2005 @ 08:47:
Nee; een beetje IDE biedt toch wel de mogelijkheid om 'watches' te gebruiken waarmee je de inhoud van variablen kunt zien.

Ikzelf gebruik VS.NET voor C++, maar voor methods die pointers of structs retourneren geldt dat je die pointers of structs bijvoorbeeld niet inhoudelijk kunt bekijken totdat ze weer aan een variabele toegekend zijn. En dan helpt een extra variabele toch een heel stuk om de overzichtelijkheid te verbeteren, imho.

Een andere situatie is wanneer je een grid van data hebt, of een datastructuur voor iets: het maakt niet uit hoe goed je IDE is, het blijft lastig om de juiste informatie uit je datastructuur te destilleren.

Misschien ligt de mate waarin je rekening moet houden met dit soort zaken ook wel aan het type applicatie en/of de hoeveelheid (exotische?) datastructuren die je gebruikt?

[Michali]

Verwijderd schreef op dinsdag 15 maart 2005 @ 11:07:
[...]
Hoe onderdruk je de foutmelding die atm aanwezig is dan? Ik snap wel dat dat kan met de @ operator alleen om dat nu bij elke functie te doen?

offtopic:
(aangenomen dat je php bedoeld:) Dat is gemakkelijk te onderdrukken met error_reporting(0); of ini_set('display_errors', 0); boven in het script. Wel handig om in je config bestandje te zetten oid.

[Verwijderd]

Verwijderd schreef op dinsdag 15 maart 2005 @ 11:07:
[...]
Hoe onderdruk je de foutmelding die atm aanwezig is dan? Ik snap wel dat dat kan met de @ operator alleen om dat nu bij elke functie te doen?

Wat dacht je van een error / exception handler? Als ik het goed heb is de @ een typische PHP operator voor het onderdrukken van fouten, en exception handling in PHP5 is de manier om goed fouten af te handelen. Lees en huiver: http://www.php.net/manual/en/language.exceptions.php

@TS: Ik probeer debug code te vermijden en gebruik configurabele logging (debug mode vs. productie mode) en IDE om te debuggen.

[pjonk]

Ik kan uit mijn ervaring vertellen dat een IDE met goede debug faciliteiten je een hele hoop tijd en ellende bespaart. Vooral in PHP miste ik de debugging voorzieningen dus dat kwam voornamelijk neer op print_r en echo statements schrijven. Persoonlijk vind ik een conditionele logging (DEBUG mode aan/uit) dan nog de netste oplossing. Een event/error log vind ik zoiezo wel thuishoren in een applicatie, want je moet bugs ook eenvoudig kunnen opsporen in productie mode.

ASP scripts debuggen is ook niet fijn en daarom maak ik voornamelijk gebruik van VB6 COM DLL's, want dan kan ik lekker in de Visual Studio IDE debuggen. Dus ik maak voor debugging zoveel mogelijk gebruik van de mogelijkheden in een IDE behalve als ik die mogelijkheid domweg niet heb.

[Verwijderd]

Het hangt gewoon van de taal en de IDE af. De meeste talen hebben een IDE die het toestaat om watches in te stellen, of gewoon door de code te steppen en de waarde van variabelen op te vragen.

In PHP heb je dat niet, of althans niet in de IDE's die ik ken. Om uitsluitend voor dit doeleinde allemaal zaken aan je code/classes toe te voegen, lijkt mij echter nonsense. Je kunt variabelen ook testen voordat je ze gebruikt; maw. er niet van uit gaan dat je krijgt wat je wil.

De error-reporting in PHP helemaal uitzetten is imo ronduit smerig, doe dat niet.

Als je er in PHP even niet uitkomt, kun je toch een simpele 'echo' gebruiken om even te zien wat er in de var zit?

[JHS]

Ik schrijf / gebruik meestal een functie / class waarnaar ik elke stap (in "leesbare" tekst) output met bijbehorende input en output, en dat alles verzameld eventueel echo, of naar een file write. Errors gaan via de error / exception handler ook naar die functie / class.

Dit heeft een aantal voordelen: ik lees precies wat er gebeurd, heb gelijk een soort van mogelijkheid voor testing en zie vaak heel snel waar / hoe het fout gaat, en bovendien is alles gelijk gecomment. Geeft al met al vaak een duidelijk beeld, alhoewel het wel wat tijd kost, maar dat bespaart het ook.

(Ja, PHP, dus niet echt een daarvoor bruikbare IDE)

[ Voor 6% gewijzigd door JHS op 15-03-2005 19:40 ]

[.oisyn]

Debuggability is bij ons een major issue, daarom hebben we naast een hele range aan debug specifieke classes en functies, ook in-class debug informatie tussen #if's (C++). In de (gold)master builds worden deze niet meegecompileerd, maar in debug en release builds zitten ze wel. En dat varieert dan van debug-info-output-functies tot een groepje extra variabelen in een class zodat een bepaalde status makkelijker zichtbaar is vanuit de debugger.

[Verwijderd]

.oisyn schreef op dinsdag 15 maart 2005 @ 20:56:
Debuggability is bij ons een major issue, daarom hebben we naast een hele range aan debug specifieke classes en functies, ook in-class debug informatie tussen #if's (C++). In de (gold)master builds worden deze niet meegecompileerd, maar in debug en release builds zitten ze wel. En dat varieert dan van debug-info-output-functies tot een groepje extra variabelen in een class zodat een bepaalde status makkelijker zichtbaar is vanuit de debugger.

In een taal als C++, C#, Delphi, etc, is dat ook prima te doen, daar je bij compilen de debug code weg kunt laten. Je release builds bevatten dan geen debug code.

Dat kan bij PHP echter niet (althans, niet voor zover ik weet). Je kunt wel een soortgelijke constructie maken waarin debug code wordt overgeslagen indien er een var op een bepaalde waarde gezet wordt, maar persoonlijk vind ik dat minder mooi. Tenzij je een IDE voor PHP vind waarmee je debug code makkelijk uit release versies kunt halen, vind ik het netter geen debug code erin te zetten. Zeker daar PHP over het algemeen minder grote projecten betreft.

Dit even afgezien van het zakelijke aspect dat je je klant alle debug code meelevert, en je het (dus) makkelijker maakt om het door een andere partij te laten debuggen..

[ Voor 8% gewijzigd door Verwijderd op 15-03-2005 21:07 ]

[CubicQ]

Ook in PHP is een soort van conditional compiling wel mogelijk: debug statement laten beginnen met // debug-begin en laten eindigen op // debug-end, en dan voor een oplevering met een search-and-replace alles tussen (en inclusief) // debug-begin en // debug-end strippen.

[.oisyn]

Daarnaast is een preprocessor voor elke taal in te zetten, ook voor PHP

[ Voor 11% gewijzigd door .oisyn op 15-03-2005 21:28 ]

[Verwijderd]

eh

Tenzij je een IDE voor PHP vind waarmee je debug code makkelijk uit release versies kunt halen,

[.oisyn]

Het hoeft toch geen IDE te zijn

Gebruik gewoon de C preprocessor en maak een makefile waarmee je je project in een keer kunt precompilen alvorens te runnen. 't Is zo gebeurd en met een goede IDE kun je dat idd automatiseren, zo'n rompslomp is het niet.

[Verwijderd]

IDE/Preprocessor.. potato, potato.. ..

Ik bedoelde dus gewoon te zeggen dat zodra je een methode hebt je debug code uit de release builds te houden, dat het dan wel verstandig kan zijn. Zolang je dat niet hebt, geen debug code opnemen imo

[Zoijar]

Verwijderd schreef op dinsdag 15 maart 2005 @ 21:49:
IDE/Preprocessor.. potato, potato.. ..

Excuse me?

[Jaspertje]

Ik doe er nu nog niet zoveel mee.. Maar zodra ik het genoegen mag krijgen Visual Studio 2005 te gaan werken, denk ik dat ik me er eens in ga verdiepen.

[Verwijderd]

Zoijar schreef op dinsdag 15 maart 2005 @ 21:50:
Excuse me?

ik ken het verschil wel hoor, het ging me er om dat je niet naar dat ene woordje moet kijken, maar naar de bedoeling er achter. De potato, potato opmerking was gewoon een grapje hoor

[MrBucket]

.oisyn schreef op dinsdag 15 maart 2005 @ 20:56:
Debuggability is bij ons een major issue, daarom hebben we naast een hele range aan debug specifieke classes en functies, ook in-class debug informatie tussen #if's (C++). In de (gold)master builds worden deze niet meegecompileerd, maar in debug en release builds zitten ze wel. En dat varieert dan van debug-info-output-functies tot een groepje extra variabelen in een class zodat een bepaalde status makkelijker zichtbaar is vanuit de debugger.

Hey kijk nou... dan ben ik toch niet helemaal gek (of iig niet als enigste)

[Verwijderd]

.oisyn schreef op dinsdag 15 maart 2005 @ 20:56:
Debuggability is bij ons een major issue, daarom hebben we naast een hele range aan debug specifieke classes en functies, ook in-class debug informatie tussen #if's (C++). In de (gold)master builds worden deze niet meegecompileerd, maar in debug en release builds zitten ze wel. En dat varieert dan van debug-info-output-functies tot een groepje extra variabelen in een class zodat een bepaalde status makkelijker zichtbaar is vanuit de debugger.

Check .