[Development] kdelibs coding style

André Pönitz andre.poenitz at mathematik.tu-chemnitz.de
Wed May 1 22:23:18 CEST 2013


On Wed, May 01, 2013 at 05:38:44AM +1000, Lorn Potter wrote:
> 
> On 01/05/2013, at 2:47 AM, Oswald Buddenhagen <oswald.buddenhagen at digia.com> wrote:
> 
> > On Tue, Apr 30, 2013 at 09:01:51AM -0700, Thiago Macieira wrote:
> >> On segunda-feira, 29 de abril de 2013 23.30.59, André Pönitz wrote:
> >>> The rules are ok as they are (pretty much as _any_ set of consistently
> >>> applied and not-completely-weird rules). Opening them up only leads to
> >>> more review bikeshedding.
> >>> 
> >>> It's not that people actively change coding style in old Qt code, and
> >>> there's always the "don't stick to the rules if it makes you look bad"
> >>> excuse.
> >> 
> >> Let's not try to change any of the rules, since this leads to bikeshedding, 
> >> like André said. It clearly has already become that.
> >> 
> > so let's meta-bikeshed instead?
> > 
> >> So let's just change the interpretation: the "don't stick to the rules" allows 
> >> us to accept a slightly different style if that makes it nicer. That should be 
> >> enough to apply to the case of braces in single-line ifs.
> >> 
> > now, that is kinda ridiculous. the cop-out rule exists to justify
> > exceptions in corner cases, not to give everyone a free pass for their
> > coding style preferences.
> 
> If I recall, it was also to give developers a little freedom in their expression.

I took it more like a "we don't want to force rules on you that make you
look stupid". There are projects with weird rules without such fallback,
and it's at times ridiculous to watch those. I am quite happy Qt takes a
somewhat more pragmatic approach here by providing the fallback. "No rules"
is bad, "too strict rules" is also bad. Somewhere in between there's a sane
middle ground. The current set of rules seems to be somewhere there.

"Giving developers a little freedom in their expression" sounds wrong,
and dangerous. I understand there are areas in the sources that must have
been written with something like that in mind. But at the end of the day,
we are not talking about an exhibition of Modern Art here. People come and
go. The code is meant to be read and understood(!) by complete strangers.
Any weirdness added, ranging from using unusual concepts to unnecessary
style deviation from what is documented, or "common", makes that harder.
As dull as it sounds: Just stick to the crowd when choosing coding style. 

Andre'



More information about the Development mailing list