Parameter names - bug 155628

[Shane H. W. Travis]

First of all, before I get into any specifics, let me get two different
things out of the way.

1) Gerv; apology accepted and appreciated... and reciprocated. I probably
should have left off responding until today, but the perceived tone of your
letter struck me in just such a way as to push one of those emotional
buttons that we all have. Thank you for recognizing that your message was
not clear, and for being the bigger man by taking steps to head off any
further misunderstandings.

2) Jouni; thank you for saying what I've been trying to say better than I've
been saying it. :)  I want to reprint his whole letter and just say, "Me
too!" at the bottom of it... but suffice it to say that what he said there
was a good synopsis of what I know the issues to be, yet why I'd like to go
ahead with it anyway. What he outlined *would* be an even bigger chore than
what I already signed up for, but I'd be willing to do it... because I think
it needs doing.

Having said that, I will respond to a couple of points in a more rational
fashion than I did on Friday. :)


On Sat, 18 Dec 2004, Gervase Markham wrote:

> >>But anyway, if we want to spend time trying to look good,
> >
> > What's this 'we'?
>
> We, as in the Bugzilla development team which we are all part of.

But see, 'we' isn't a monolithic entity... and that's sort of my point. Some
people don't think that it's a worthwhile use of time to try and 'repair the
past' and bring old code up to current spec. Some do. I'm in the latter
camp, but I also know that it's a large job... and one that has a potential
to cause side-effects.

I came to ask people how many side-effects are worth the benefit of cleaner,
more consistent, more readable code. For some, I guess, the answer is 'none
at all'. My hope was that more would see the benefits, and be willing to
offer suggestions on ways to minimize the disruptions while still
accomplishing the task... like Jouni did.


> However, no man is an island, and the actions of one developer on the team
> have an effect on the others - in the code they have to maintain, the
> support questions they have to answer, and the bugs they have to fix.

Absolutely. My motivations (whether or not you agree that they match with my
actions) are that I'm trying to *reduce* that load -- over the long term.
'How much long-term gain is this, and how much short-term pain is it worth?'


> I did suggest one, which was to modify the plan to use aliases so that
> external code was not broken.

This is the point I really wanted to address -- the 'aliases' thing.

As I understand it (and I submit as given that my understanding may be
faulty), aliases are an indirect way of referring to an underlying parameter
so that they so that they can be referred to in a more user-frendly manner.
For example "commentonclose" could be aliased to "Require a comment when a
bug is closed." This is a good thing, no question about it. I would support
such a thing. In fact, it is my understanding that Dave is already *doing*
exactly such a thing as part of his multi-panel editparams fix (bug 46296).

When Myk filed bug 15628, it pointed out a rusty bike (params not consistent
and hard to read), and said that the rust should be removed (add underscores
to param names). Dave's multi-panel editparams is putting a coat of paint
over the rust (aliases, so the params aren't visible), which fixes the
*visible* problem. It doesn't do anything to actually attack the rust,
though... which is what I'm offering to do.

I agree that painting the bike will make it more attractive, and more
interesting to others. That's great! I know that some people *like* painting
(just as others like redesigning the brakes, or adding a new headlight and
reflectors, or improving the gear mechanisms). Me, I think that it's worth
getting rid of the rust before applying the paint, and I sort of *like*
doing that. (That, and writing instruction manuals. :-) )


So, in a very roundabout way, I hope that answers the question, Gerv. Yes,
aliases would fix it so that the EXTERNAL code was not broken, but I'm not
just interested in the externals. I like to fix things so that they're done
'right' -- consistent, documented, easy to read, easy to maintain. That's
why I took this bug - because (I thought) it offered an opportunity to do
just that.

Painting is fine, but I'll leave that to someone more artistic than me. :)

Anyway, thank you to *everyone* who participated in the discussion. Dave has
indicated that he'll make a go/no-go decision sometime today, in case anyone
has anything else to say.


Shane H.W. Travis       | Anyone who is capable of getting themselves
travis at sedsystems.ca    |  made President should on no account be allowed
Saskatoon, Saskatchewan |  to do the job.  -- Douglas Adams, HHGTTG