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

List:       kde-core-devel
Subject:    Re: kdelibs coding style
From:       Frerich Raabe <raabe () kde ! org>
Date:       2006-08-23 10:38:32
Message-ID: 200608231238.33017.raabe () kde ! org
[Download RAW message or body]

On Wednesday 23 August 2006 12:21, David Faure wrote:
> On Monday 21 August 2006 21:17, Leo Savernik wrote:
> > Am Montag, 21. August 2006 16:44 schrieb Dirk Mueller:
> > > for example switch() indenting
> > > rules are unclear to me
> >
> > While you're at it: I want to mention that Kate's smart indenter handles
> > switches like this:
>
> And I'd like to mention that the xemacs setup we have been using for many
> years doesn't indent the case statement, therefore a lot of existing code
> does NOT indent the case.
>
> > I. e. the case statement is indented, too. Therefore, I ask the TWG to
> > take into account this existing precedent within KDE. It's less error
> > prone to make the rules match the code instead of the other way round
> > (especially as the rules don't exist yet).
>
> But the rule for case does match a lot of the existing code, you must be
> looking at different code than the one that was written by developers using
> xemacs...

And I suppose simply saying "You're free to indent the statements in a case 
branch of a switch if you want." is not acceptable by the coding style 
police? I don't want to start a flame war but I never quite understood why 
you have to define all such things to 100%, as long as common sense stuff 
like "Don't write the body of an if statement on the same line" or something 
like that is agreed on.

I think if you have developers on a project who are more 'productive' because 
it's easier for them to understand code which has tiny cosmetic things like 
indented case statements, then you have bigger problems than an inconsistent 
indentation style. :-}

- Frerich
[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic