idiom for debug code?

[Dan Perl]

I was not thinking of actually removing code.  The analogy to C++ 
preprocessing was just an example.  I am looking at something that can be 
determined at run-time, not compile-time.

And you're right, I'm not really concerned about the overhead of an "if" 
because I will not use this extensively anyway.  This problem occurred to me 
when I decided to add an import for win32traceutil.  I'm looking for a way 
to have that permanently in the code and enabling/disabling it only at 
run-time.

I have thought of alternatives like an environment variable or a 
configuration parameter, but I was looking for other ideas.  I thought this 
should be a common issue and that there could be an idiom for it.

Dan

PS: in the case of importing win32traceutil, I guess that checking the 
environment would be necessary anyway, or the import should be in a try 
statement, ignoring the exceptions.

"Larry Bates" <lbates at syscononline.com> wrote in message 
news:wfmdnXvIef4v1cHcRVn-vQ at comcast.com...
> Dan Perl wrote:
>> Is there a mechanism or an idiom for adding code for debugging so that it 
>> can easily be removed in the production code?  I am thinking of something 
>> similar to the C/C++ preprocessor statements with which you can compile 
>> an application with the debug code or without it (the default).
>>
>> Dan
> Personally I think you should consider NOT removing the debugging code.
> It never ceases to amaze me how many times I must have a client run
> the application with debug set so that the program logs details about
> the running process and intermediate results.  The output logfile can
> then be easily emailed, faxed, etc. to me so that I can determine what
> is REALLY the problem.  The overhead of these if _debug: "type"
> statements seems incredibly low compared to the ability to get this
> information when needed.  Just some thoughts based on my experience
> of the last 30+ years.
>
> Larry Bates
> Syscon, Inc.