From kde-core-devel Sat Jul 22 21:14:28 2006 From: Henry Miller Date: Sat, 22 Jul 2006 21:14:28 +0000 To: kde-core-devel Subject: Re: kdelibs coding style Message-Id: <200607221614.29471.hank () millerfarm ! com> X-MARC-Message: https://marc.info/?l=kde-core-devel&m=115372831911070 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.