This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


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

Re: [patch] TODO more cleanups


"J.T. Conklin" wrote:
> 
> >>>>> "Eli" == Eli Zaretskii <eliz@delorie.com> writes:
> >> To expand a little on the comment attatched to STREQ().  The intention
> >> is that the person rewriting the STREQ() calls does more than hope that
> >> the changes work.
> 
> Eli> Can you tell why this is at all a Good Thing?
> Eli>
> Eli> I've seen projects that argue whether or not to replace strcmp with
> Eli> STREQ, but this is the first project that wants to do the opposite...

I don't expect anyone (apart from me) to be sufficiently anal to
actually bother to go through and purge the code.  However, ... :-)

J.T. explanation is correct.  I'll just add a few more philosophical
observation that may help explain why I'm generally positive towards
people eliminating conventions.

The first one is that the coding conventions should be a simple as
possible.  Unless something has a clear long term advantage then I don't
think it should be adopted.  For instance, xmalloc() is accepted because
it eliminates the age old problem of people forgetting to check for a
NULL pointer.  I don't think STREQ() passes this test - while cute, it
doesn't offer any real advantages.  The programmer reading the code is
never 100% sure how the macro has been implemented.

The coding conventions need to achieve critical mass.  By this I mean
that the convention is accepted as the norm.  Again xmalloc() has
achieved this, if someone uses malloc() in the GDB code it will
immediately raise eyebrows.  There is no dispute over its use.  I don't
think STREQ() passes this test - it has only been used where people
(incorrectly?) thought they should micro optomize the code.

The other observation is about how, in long lived projects, bad
conventions have this ability to spread like cancer.  Something slips in
and next thing you know its been copied N times and spread its way
through out the code base.  This is why I have a preference for either
eliminating conventions that didn't prove beneficial (STREQ()) or fully
implementing conventions that have been adopted (function prototypes).

	enjoy,
		Andrew

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