httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <>
Subject Re: cvs commit: apache-1.3/src/modules/standard mod_expires.c mod_include.c mod_log_config.c mod_rewrite.c mod_usertrack.c
Date Mon, 30 Mar 1998 02:36:14 GMT
But naming something like that is a lot like microsoft's hungarian
notation, which is supposedly useful for something that I'm not clear on.
"char *pByte"?  Wow that's such a useful name!  So much more useful than
"char *str". 

Documentation is documentation, it shouldn't be enforced as part of the
symbols.  You'll notice that I put a bunch of documentation into the
header file where I defined (the now-named) ap_vformatter.  That is how we
should document our API.  Every function which is part of the API should
be documented like that, and NOTED as being part of the API (or part of
whatever sub-part of whatever interface you want to talk about).

If it's not part of the API but exported anyhow then say that where the
function is documented.  Folks ignoring the documentation get exactly what
they deserve: no forward compatibility. 

But to make us type "apapi_" or "appri_" or whatever is a complete waste
of screen width, and typing time. 


On Sun, 29 Mar 1998, Jim Jagielski wrote:

> Dean Gaudet wrote:
> > 
> > This is ridiculous.  Apache is 72k lines of code.  If we can't keep our
> > own symbols from colliding with each other then we've got serious problems.
> > We need only one prefix.
> I think the whole idea was some sort of logical use of prefixes to
> better define the API and which functions are public, private, whatever.
> I think that makes sense... It's real easy for 72k lines of code
> to become a mess that no one can read or understand.
> -- 
> ===========================================================================
>    Jim Jagielski   |||   |||
>             "That's no ordinary rabbit... that's the most foul,
>             cruel and bad-tempered rodent you ever laid eyes on"

View raw message