Re: Style proposal [Re: Coding style changes of 2009-06-26 now in the guidelines]

[Michael Widenius]

Hi!

>>>>> "MARK" == MARK CALLAGHAN <mdcallag@stripped> writes:

MARK> On Wed, Oct 21, 2009 at 2:41 AM, Michael Widenius <monty@stripped>
> wrote:
>> 
>> Hi!
>> 
>>>>>>> "Ingo" == Ingo Strüwing <Ingo.Struewing@stripped>
> writes:
>> 

MARK> [cut]

>>>> I would also suggest that you never accept a code style
>>>> convention that is not accepted by those that are affected by it
>>>> (I those that produced code to MySQL or it's variants).
>> 
Ingo> Agree. That's the reason why I raised a request for ideas, how this
Ingo> could be done transparently. I would like to have a voting system that
Ingo> accepts a vote from everybody, who works with MySQL code directly, and
Ingo> refuse votes from other people.
>> 
>> Sounds much better than the current procedure.  Note that to get this
>> right, the vote should also be weighed with how much cod on has
>> produced in the code base!
>> 

MARK> Has produced?
MARK> Or will produce?

You can't know how much code a person WILL produce. The only thing you
can be sure of is the past and the contribution the person has already
made.

>> After all, we don't want to have people that commit a lot of code to
>> not agree with the coding style that is imposed on them and makes the
>> code harder (for them) to read and write.

MARK> For this reason votes should be weighted by:
MARK> * how much code each person will write
MARK> * how much code each person will read

Don't know how one can judge how much code a person will read or how
to prove that.

MARK> What are the scale factors for:
MARK> * code read/written in the past versus to be written in the future?
MARK> * code read versus code written?

That is open for discussion

MARK> Do you get votes for lines removed?

If we count size of approved 'diffs' with non trivial changes, then yes.

MARK> Do votes get transferred from author to bug fixer when someone fixes
MARK> bugs in said code?

No.

MARK> Do you get votes for ports or backports? I know people who worked very
MARK> hard to backport batch key access and connection pool. They deserve
MARK> some votes for that effort. But when a port is as simple as running
MARK> patch, fewer votes should be assigned.

Yes, backporters are definitely working on the code, but it's not as
much worth as writing new code.

MARK> Do you get votes for whitespace? Heikki uses much more whitespace in
MARK> InnoDB. Perhaps he saw this coming and tried to inflate his vote
MARK> count. Heikki is very clever.

:)

MARK> If votes also get assigned for code read, then we should strive to
MARK> make our code as unreadable as possible to avoid diluting our votes
MARK> for writing it.

Good idea.  If we make the code so hard to read, everyone has to read
the same lines many times, then it causes more reads of others, which
is a good thing, isn't it ;)

MARK> Do you get votes for comments? Given the lack of comments in header
MARK> files I think I know the answer to that. But I think that we should
MARK> give out votes for lines of comments. I would use comments to scare
MARK> away readers and avoid diluting my votes.

Comments that contains useful, non trivial information is of course
valuable.

MARK> I think there should extra votes if you read code and then write a
MARK> unit test for it.

All code that is added to the source should of course be tested.

MARK> Does work done on branches other than the official MySQL branch count?

As long as the code is available under some open source license, yes,
of course.  We are a big happy family, aren't we?

MARK> Maybe we could extend the 'karma' feature from Launchpad for this and
MARK> only count votes for work done on branches there. But I did a lot of
MARK> work on non-Launchpad branches so that makes me unhappy.

If the code is released somewhere, don't see a problem with it.

Regards,
Monty