[PHP] debug code

[Michali]

Ik ben eigenlijk benieuwd hoe jullie debug code in jullie php code verwerken. Bepaalde statements zijn namelijk erg handig tijdens het ontwikkelen (logs bijhouden van queries, output logs, variabel logs, asserts), maar veel van die zaken wil je er natuurlijk niet in hebben in de werkelijke code vanwege performance redenen etc. Nu wil ik dit zelf oplossen door alle debug code op deze stijl te plaatsen:

PHP:

function doeIets()
{
  #START_DEBUG#
  // hier alle debug code
  #END_DEBUG#

  // de rest van de code
}

Nu wil ik een scriptje maken welke de complete directory uitleest en deze aangepast weer neerzet in een andere directory (uiteraard zonder de bron aan te passen). Ik heb dan 2 directories, debug en production, welke de versies met dezelfde naam moeten representeren. Met behulp van regexjes wil ik zo alle comments, alle debug code en alle ruimte (spaties, tabs en newlines) groter dan 1 spatie vervangen met 1 spatie (klinkt eenvoudiger dan het is, want dat mag niet overal natuurlijk, maar daar ga ik even niet verder op in). Zo houd ik dus minimal code over welke dan iets sneller moet lopen dan de debug versie.

Passen jullie ook zulke technieken toe of verwijderen jullie met de hand debug regels, of commenten julie ze eventueel? Mischien nog andere leuke handigheden of tricks voor tijdens het ontwikkelen?

[Paul]

Ik heb geen ervaring met PHP, alleen met gecompileerde talen

Omdat dat soort talen altijd een fatsoenlijke IDE met debugger hebben, schrijf ik eigenlijk weinig debug-code, en als ik het al doe overleeft die code alleen de bug waarvoor deze geschreven is, daarna haal ik hem weer weg.

Commentaar, inspringen etc strippen heeft bij een gecompileerde taal ook weinig zin.
Wat ik me nu echt afvraag: heeft het bij PHP wel zin? Heb je / heeft iemand dat ooit getest?

[GambitRS]

Ik merk dat het gebruiken van de juiste tools al een hoop debug code scheelt. Eerst gebruikte ik Editplus2, die de code helemaal niet controleerd en vaak had ik ook debug code nodig. Door over te stappen op Zend is dit zo drastisch gereduceerd dat ik nu nauwelijks debug code hoef te gebruiken. Bovendien heeft Zend zijn eigen debug features wat het een stuk makkelijker maakt.

[Michali]

Erg veel debug code heb ik ook niet nodig. Maar ik vind het bijvoorbeeld wel handig om asserts uit te voeren op functie parameters die belangrijk zijn etc. En om die nou handmatig te gaan weghalen als er een nieuwe versie gereleased wordt en weer terug stoppen als ik weer ga debuggen. Dat vind ik een beetje tijd verspilling. Verder vind ik het strippen ook een stukje bescherming van de source code. Ik wil niet gaan encrypten, maar op deze manier is het toch iets lastiger door te lezen. Ik weet niet zeker of dat erg veel performance scheelt, ik denk het niet, maar die debug regel wel iig. Zeker als ik een stuk of 5 log bestandjes wegschrijf iedere keer als ik een actie uitvoer.

En die log bestandjes heb ik vaak genoeg nodig. Ik kan van een XUL pagina de source bijvoorbeeld niet opvragen. Dan is het fijn als die even wordt weggeschreven. En ik bouw queries op een generieke manier op. Dit wil ik ook altijd even testen. Bovendien wil ik ook bijhouden hoeveel er nou gequeried wordt om zo eventueel optimalisaties uit te kunnen voeren. Daarnaast heb ik ook nog wat eigen profile/benchmark code welke ik wil weghalen uit de 'echte' versie.

[ Voor 26% gewijzigd door Michali op 10-04-2005 14:16 ]

[PrisonerOfPain]

Michali schreef op zondag 10 april 2005 @ 14:13:
En die log bestandjes heb ik vaak genoeg nodig. Ik kan van een XUL pagina de source bijvoorbeeld niet opvragen. Dan is het fijn als die even wordt weggeschreven.

In Firefox adressbar: view-source:http://www.xulplanet.com/tutorials/xultu/examples/ex_buttons_1.xul

[T-MOB]

Net even een bemchmarkje gedraaid (meten is weten he). Maar het weghalen van whitespace en comments om performance redenen is onzin. Er was geen signiicant verschil tussen 10.000x een loopje op één regel en hetzelfde loopje met 100 regels comment en whitespace.

Het weghalen van comments en whitespace om je source te "beschermen" vind ik helemaal onzin. Haal het spul dan gewoon door de zend-encoder ofzo. Dat scheelt ook nog écht performance. Misschien ben ik een beetje een hippie, maar als je toch source aan het verspreiden bent, zorg dan dat het nette code is. Dat is niet alleen een beter visitekaartje, maar als jij over X jaar onvindbaar bent is je code tenminste niet waardeloos.

[Michali]

T-MOB schreef op zondag 10 april 2005 @ 15:01:
Net even een bemchmarkje gedraaid (meten is weten he). Maar het weghalen van whitespace en comments om performance redenen is onzin. Er was geen signiicant verschil tussen 10.000x een loopje op één regel en hetzelfde loopje met 100 regels comment en whitespace.

Het weghalen van comments en whitespace om je source te "beschermen" vind ik helemaal onzin. Haal het spul dan gewoon door de zend-encoder ofzo. Dat scheelt ook nog écht performance. Misschien ben ik een beetje een hippie, maar als je toch source aan het verspreiden bent, zorg dan dat het nette code is. Dat is niet alleen een beter visitekaartje, maar als jij over X jaar onvindbaar bent is je code tenminste niet waardeloos.

Daar heb je wel een punt. Mischien haal ik zo ook problemen op de hals die nergens voor nodig zijn. Maar maar die debug regels haal ik wel weg. Dat lijkt me nog steeds handig.