[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: kdelibs coding style
From:       Henry Miller <hank () millerfarm ! com>
Date:       2006-07-22 21:14:28
Message-ID: 200607221614.29471.hank () millerfarm ! com
[Download RAW message or body]

On Saturday 22 July 2006 14:25, Maks Orlovich wrote:
> No, it's not. Yes, the proposed policy itself affects only kdelibs. But
> the /nature/ of the policy affects everyone. This sets a precedent that
> something that's merely a matter of preference and not technical merit can
> be legislated as a policy in the project. 

Sometimes you need to do this.   Nearly everyone is in agreement that any law 
is better than none.   If the coding style called for such absurd things as 
50 space tabs, and no newline after braces, we would adjust, because it was 
at least a clear rule.    In this case a clear rule is better than no rule at 
all.

> And in fact, even making kdelibs 
> different in a way that's not technically neccessary (constract with e.g.
> BC), introduces a small but existing psychological barrier for contributors
> to jump into kdelibs from other modules.  (And don't bring up kdepim,
> please. kdepim also has a long-lasting reputation for being hostile to new
> contributors).

This is technically necessary.  The easiest code for someone to read is code 
that was written in the same way they would have written it.  Since not 
everyone writes code in the same way, we have to find a compromise.    The 
worst compromise is what KDE has now: everyone writes code the way they like.   
(Though some do try to find the style of the current file)   A much better 
compromise is one where all files are in the same style - no matter what the 
style is.

While it is somewhat difficult to adjust to a new style, this is not the 
difficult part of writing new code.   We should assume that most new 
programmers will not follow the style correctly.   Somehow (and this can be 
hard after many patches from new codes) we need to be patient with new codes, 
bringing them up the speed one the style.   It is important, but we need to 
take care not to become frustrated when someone fails to follow the standard 
until reminded

I propose (but you will note that my contributions to KDE are so tiny as to 
not count) that discussions of changing the style, once implemented, are off 
limits unless there is a good TECHNICAL reason to change it.    Beauty of 
code (once a style is implemented) is not a valid reason to change the style.  
Standards of beauty change all the time.  (Go look at some old pictures if 
you don't believe me, then ask if people dress the same now)     If the 
argument cannot be made purely on objective grounds, it should not be brought 
up.

The only objective thing I can come up with is if the C++ standard committee 
published a style guide, and then the discussion should be not on the content 
of the style (assuming it is reasonable), but if it is worth adjusting to 
standard.    This is not likely to happen.  
[prev in list] [next in list] [prev in thread] [next in thread]