From kde-core-devel Wed Aug 23 14:47:54 2006 From: Lubos Lunak Date: Wed, 23 Aug 2006 14:47:54 +0000 To: kde-core-devel Subject: Re: kdelibs coding style Message-Id: <200608231647.55078.l.lunak () suse ! cz> X-MARC-Message: https://marc.info/?l=kde-core-devel&m=115634449625037 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