Re: [boost] in/out parameters, codingstylesandmaintenance

From: Justin M. Lewis (boost_at_[hidden])
Date: 2003-05-02 15:45:41

It's not incomplete.  In my experience, the vast majority of unrecognized
calls in code are specific to that project.  You wouldn't have to use these
structures all over the standard C/C++ libraries for them to be useful,
everyone already knows what all those calls do.  These classes would be
useful in unfamiliar code, code that is specific to a project.

Having 3rd party libraries that don't use this technique doesn't negate its
usefulness.  Again, in my experience, most of the code written in a project
is in house, it's not a big congolmeration of 3rd party libraries.  You
might bring in something like boost, but it's well documented, and would
probably be well understood by anyone who worked on the project for even a
short amount of time.  The confusion is when you have literally 1000's of
files worth of in house code that needs to be sorted through to determine
where a variable might be changing on its way through all of that.

So, if these objects are used consistently throughout a project on all the
in house code, it fulfills its purpose 100% by making all of those
unfamiliar calls clear.

And, in response to Bo Persson's latest response, since I can't reply to it
directly because of some outlook express quirk.

"My point was (should have been?) that you can choose names so that they
tell
you what is going on. There should be no need to add extra qualifiers to
point out what you really intended."

It's not that simple.  You can't name a function to tell you how every
parameter to the function is being treated, unless you want function names
like:
get_something_modifies_first_param_uses_2nd_param_to_generate_value_returned
_in_2nd_param_3rd_param_used_to_generate_1st_param(int &x, int &y, const int
&z);

Assume that sscanf isn't part of the standard C library, and it's unfamiliar
to everyone, the call looks like
sscanf(mystr, "%d %d", &x, &y);
can you really look at that and tell that mystr is constant, and can you be
sure that x and y change, without looking it up?  No.  So, how would you go
about naming a function like that so that it's effect is clear?  Proper
naming isn't a realistic solution to this problem.  And, while you may think
the name makes the outcome clear, that doesn't mean that it's obvious to
everyone else, so anyone who doesn't understand your naming convention is
still left in a position where they have to go looking up your functions,
and any functions your function calls, to see if a parameter is changing.
Making it ridiculously hard to determine which of the 100 calls in a
function you're looking at might be modifying the data you're trying to
trace.

Justin

----- Original Message ----- 
From: "Joel de Guzman" <djowel_at_[hidden]>
To: "Boost mailing list" <boost_at_[hidden]>
Sent: Friday, May 02, 2003 8:18 AM
Subject: Re: [boost] in/out parameters, codingstylesandmaintenance

> Noel Yap wrote:
> > Joel de Guzman wrote:
> >>> But I don't think that a lack of global usage
> >>> guaruntees hinders the potential usefulness of the idea.
> >>
> >> Why? If it's not applied globally, it would be like installing some
> >> security alarm system only in some places in your house. How useful
> >> is that?
> >> There would still be uncertainty.
> >
> > IIRC, at $70.00/window and possibly over a couple of dozen windows,
> > most don't use the security system for every possible entrance to
> > their
> > house, at least not all at once.  How did you go about doing it?
>
> <ot>
> I don't. No offense meant, but I think such incomplete security systems
> are useless. Wasn't that my point?
> </ot>
>
> -- 
> Joel de Guzman
> joel at boost-consulting.com
> http://www.boost-consulting.com
> http://spirit.sf.net
>
> _______________________________________________
> Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
>