This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Standard scheme for maintainer-only debugging code?


>>>>> "Nathanael" == Nathanael Nerode <neroden@twcny.rr.com> writes:

 >> I'd be very careful with this.  Whetever we decide, we surely must
 >> not do anything that might dissuade developers from leaving in
 >> place code that will aid a future maintainer.  Even if such code
 >> is bit-rotted and needs fixing it can still be enormously helpful.
 >> However, develeopers don't want to bloat the compiler with all
 >> their debugging stuff.
 >> 
 >> #ifdef DEBUG_BARF code has saved my tail more than once.

 Nathanael> Exactly.  But it's no good if a later developer can't find
 Nathanael> it.

 Nathanael> That's why I want a *standard* scheme for DEBUG_BLAH
 Nathanael> conditionals; so that it's clear what the point of the
 Nathanael> section was.

 Nathanael> Things are #if 0'ed out for other reasons, such as
 Nathanael> temporary breakage; they're #if FOO'ed out for accidental
 Nathanael> reasons, such as when FOO used to be used and is no
 Nathanael> longer; etc.

 Nathanael> Making it clear which disabled code is in fact for
 Nathanael> maintainers' debugging use is a Good Thing.

Ditto for other reasons.  It would be good if the name of the flag
suggests what the intent was.  The most confusing kind of
commented-out code I've run into is stuff tagged with "#ifdef
NOTYET".  That suggests work in progress, but often it's ancient cruft
instead...

	paul


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]