MySQL Lists are EOL. Please join:

List:Internals« Previous MessageNext Message »
From:Ingo Strüwing Date:July 1 2009 8:04am
Subject:Re: [style] [annc] Coding style update
View as plain text  
Hi Monty,

Michael Widenius, 30.06.2009 03:05:

> In the past when we had votes for coding style changes in MySQL,
> everyones vote counted!

I am with MySQL since the beginning of 2004. I cannot remember any poll
for votes from the community. So either you are wrong, or there was no
change of coding style in five years. Since the procedure for coding
style votes has not been documented, and no one pointed out, how it was
in the past, one has now been created from scratch.

Perhaps it would help if you could write down, how the procedure for
polls has been formerly.

Er, stop. I remember one case. During the company meeting in Cancun, we
had a poll regarding tabs or spaces. It was decided by hand-raise of the
people, who were present. I don't think that the community was present.
Nor all MySQL developers were.

In general I wonder, how much enthusiasm we spend on style decisions.
After all these are a matter of taste mainly. In contrast, very
important design decisions can be made by three arbitrary people, one
developer and two reviewers. If we can accept that, why can't we accept
taste decisions to be made by a small committee? Is tasteful looking
code so much more important than good design?

> By the way, when it comes to doing changes that this that affects
> style, the best thing would be to do it the following way:
> - Agree on a change.
> - Go trough all active MySQL releases (the ones you will sooner or
>   later merge from)
>   - Fix code completely in one release (with some macro/program)
>   - Merge to next version
>   - Fix things in that version.
> - Work with the community with all active forks to help them do the
>   same.

We have never done this before, as far as I remember. When you
introduced function comments, they were added to new or gravely changed
functions only. Not to all existing functions. When you decided to have
space after an assignment operator and after commas, not all old code
was fixed. When we decided, not to use tabs, it was applied to new lines
of code only. Not all tabs from all files were replaced.

Hence it is just consistent, not to apply new style changes to all old code.

> In some part it's good that there is a committee for coding style
> changes as I think it's their job to ensure that the above is done,
> either by getting someone to do it or by doing it themselves.

For the proposals I made, I would be happy to do the changes, if asked
for. But I do not suggest to perpetrate such merge hell.

> If you don't do this, you will never get a new code style used as
> people will always copy code from one place to another and there will
> be new code with the old style.

The style change, I mentioned above, are followed, though old code was
not changed. Same will work for the new changes too. More or less.
Sooner or later.

Ingo Strüwing, Database Group
Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Geschäftsführer: Thomas Schröder,   Wolfgang Engels,   Wolf Frenkel
Vorsitzender des Aufsichtsrates: Martin Häring   HRB München 161028
[style] [annc] Coding style updateKonstantin Osipov29 Jun
  • re: [style] [annc] Coding style updateMichael Widenius30 Jun
    • Re: [style] [annc] Coding style updateKonstantin Osipov30 Jun
      • Re: [style] [annc] Coding style updateMichael Widenius30 Jun
        • Re: [style] [annc] Coding style updateAlex Esterkin1 Jul
    • Re: [style] [annc] Coding style updateIngo Strüwing1 Jul
  • Re: [style] [annc] Coding style updateTor Didriksen2 Jul
    • Re: [style] [annc] Coding style updateGuilhem Bichot2 Jul
      • Re: [style] [annc] Coding style updateTor Didriksen2 Jul
        • Re: [style] [annc] Coding style updateTor Didriksen2 Jul
          • Re: [style] [annc] Coding style updateGuilhem Bichot2 Jul
      • Re: [style] [annc] Coding style updateIngo Strüwing2 Jul
  • Re: [style] [annc] Coding style updateTor Didriksen3 Jul