Re: [boost] Re: in/out parameters, codingstylesandmaintenance

From: Justin M. Lewis (boost_at_[hidden])
Date: 2003-05-03 17:04:58

----- Original Message -----
From: "Terje Slettebø" <tslettebo_at_[hidden]>
To: "Boost mailing list" <boost_at_[hidden]>
Sent: Saturday, May 03, 2003 2:37 PM
Subject: Re: [boost] Re: in/out parameters, codingstylesandmaintenance

> >From: "Justin M. Lewis" <boost_at_[hidden]>
>
> > > > Looking a function signature up becomes a nightmare when there are
> > > > potentially 100's of them.  So, that's hardly a realistic solution.
> > >
> > > I think it is.
> >
> > If you think it is, then you've never been in the situation where you
have
> > 1000's of undocumented functions, and you've never had to trace through
a
> > function where 10's if not 100's of unfamiliar calls are made.  And, if
> you
> > think it is a realistic solution, then you're really not seeing the
> problem
> > these classes were meant to address.
>
> Yes, I'm seeing it. It's just that there are alternative solutions to
this,
> as has been presented.

There really aren't reasonable alternative solutions, at least not in my
case.

The thing that originally started all of this, started my original
discussion with someone at work, and then later with the people on the C++
IRC channel, was when I was doing code coverage analysis.  Trying to trace
back to find why a certain piece of code wasn't hit.  Tracing variables
back, looking for where they changed and why, and realizing in some
instances there were NO var_Im_interested_in = instances, so it was being
changed inside a function somewhere, so start searching for the function
that might change it only to realize that a the var is passed to a lot of
different functions from our project.

So, IF my idea had been used, instead of looking for each function call,
then having to go look up each function for each var I'm interested in to
see the prototype, I could have done a couple quick searches
var =
out(var)
in_out(var)

Or, at the very least, I could just look for var, and see which functions it
was passed to wrapped in out or in_out.  And, eveything would have been fast
and easy.

So, EVEN in the case where out and in_out aren't universally used, since
this is a favorite argument coming from people, EVEN in that case, if out
and in_out were inconsistently used, it would at least give me a good solid
starting point.  And, in the case where it is universally used throughout
the project, I'd have all the information I need for a clear understanding
of what's happening to my variable throughout the code I'm tracing it
through.

>
> > Again, old code doesn't need changed, because we all ARE familiar with
> > sscanf, but, you wanted examples of people using out or in/out params,
and
> > there you go, there's an example.  And I said, pretend it's NOT a part
of
> > the standard C library, pretend it's not a call that everyone is
familiar
> > with, try to give it a name such that it explains how all of the params
> are
> > used.  It's my example of why naming convention isn't a reasonable
> solution.
>
> And I gave an answer: No naming change is needed in this case, as it's
clear
> from the type of arguments passed in.
>
> > > In such an environment, your in_out() and out() parameters may be the
> > first
> > > to go, as people won't bother to use them, and change the signature to
> not
> > > use them (or provide an implicit conversion to them.
> > >
> > > Anyway, if you think it's a good idea, why don't you try it out?
Letting
> > the
> > > rubber meet the road may be way more productive, than trying to
convince
> > > people, without existing practice to refer to.
> >
> > Of course they'll be used, if they're already a part of the code, people
> > aren't going to go strip them out.  Modifying code in a large project is
a
> > PITA.  Besides, no one is going to go modify code they didn't write just
> to
> > save them from having to type 5-8 extra bytes.
>
> No?
>
> CVS diff log for in_out.hpp:
>
> Commit message: I'm not going to bother with using in_out()
>
> template<class T>
> class in_out
> {
> +    in_out(T &v) : value(v) {} // So sue me
> ...
>

If someone did that, the message would go out to everyone, and, hopefully
someone would complain and undo the checkin.  I would certainly go undo the
checkin.

> Seriously, though, this was mostly to try to lighten up this thread a
> little.
>
> > But, if your argument is
> > people are going to go out of their way to destroy clear coding styles,
> > then, again, all of the solutions anyone else has proposed are at least
as
> > likely to be thrown out.
>
> No, people may remove something, if they think they are better off without
> it.
>
> > And, again, I HAVE been using these classes.  That's why I brought them
> > here.  I had a problem with functions not being clear, I found a
solution,
> > that's enforceable, in that people using the libraries I write have to
> > adhere to it, I know other people like the idea after having discussions
> > with them, so I thought I'd see about giving it to boost and having it
out
> > there where it's easily accessible to a large number of people.
>
> And you have got feedback.
>
> Some of the problem, with this is that readability is very subjective, so
> discussions of coding style, what is more readable or understandable
> function may be difficult. What some may consider making something more
> clear, other may consider it the other way around.
>
>
> Regards,
>
> Terje
>
> _______________________________________________
> Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
>