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

List:       kde-core-devel
Subject:    Re: kdelibs coding style
From:       Lubos Lunak <l.lunak () suse ! cz>
Date:       2006-08-23 14:47:54
Message-ID: 200608231647.55078.l.lunak () suse ! cz
[Download RAW message or body]

On Wednesday 23 August 2006 13:02, David Faure wrote:
> On Wednesday 23 August 2006 12:38, Frerich Raabe wrote:
> > 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. :-}
>
> I completely agree. I think the specification of the little details is
> simply there so that people who *want* a styleguide to follow can get one.
> And for people programming the customization of the editors (I like when I
> can just use C-c C-q in xemacs to reindent the current method correctly;
> where the styleguide defines what 'correct' is).
>
> For existing code and future contributions, we shouldn't be too strict
> about those rules, as long as the main ones are respected (indentation).

 So we're going to have a guide that's pretty strict even about things like 
placement of spaces but not actually require it? How about we then make a 
list of really required things[*] and call the rest just "recommendations" or 
whatever, because that's what it's going to be anyway? (Do I have to say that 
I told you?)

[*]
- Indent by 4 spaces, no tabs
- Try to make it readable, use common sense, follow the style of the file
- Anything else?

> Well, I think we can wrap this up now - editor-specific config-files have
> been added to kdelibs (like .emacs-dirvars), all we need is to add the
> kdelibs-coding-style to some webpage, I guess on developer.kde.org...

-- 
Lubos Lunak
KDE developer
--------------------------------------------------------------
SUSE LINUX, s.r.o.   e-mail: l.lunak@suse.cz , l.lunak@kde.org
Lihovarska 1060/12   tel: +420 284 028 972
190 00 Prague 9      fax: +420 284 028 951
Czech Republic       http//www.suse.cz
[prev in list] [next in list] [prev in thread] [next in thread]