Getting Style

[Milian Wolff]

On Friday 20 April 2012 21:44:14 Andreas Pakulat wrote:
> On 20.04.12 19:29:31, Milian Wolff wrote:
> > Hey all,
> > 
> > I want to make our code base better readable and use a consistent style
> > for
> > *all* our codebase, including external plugins, cmake support, cpp parser,
> > etc. pp.
> > 
> > We discussed this previously, but quite frankly I forgot the outcome. But
> > before we start the trollwar on tabs vs spaces, some important notes:
> > 
> > # blame without space commits
> > 
> > I found out that one can use "git blame -w" to annotate a file but
> > ignoring
> > whitespace changes, which is very helpful. This of course won't help with
> > other style changes like adding braces, fixing typos and such, but still
> > this is a very big improvement. Imo we should even make this the default
> > when using "annotate file" in kdevelop.
> 
> Does this handle whitespace anywhere in the line? (it probably does, but
> the manpage is not very extensive on this)
> 
> > # now, what style?
> > 
> > So, I hope you agree that with the above, a run over *all* our code bases
> > with uncrustify would be feasable and very useful.
> 
> FWIW: I disagree that such a "reformat all sources" has any real value.
> If there are pieces of code which are hard to understand/unreadable,
> thats ok to reformat in my opinion. I don't think we have many of such
> cases though. The only reason I could see to do this might be if you
> notice that the formatting makes contributing much harder.
> 
> That being said, even though I disagree that this is very useful I'm not
> objecting doing this mass-reformatting.

>From my experience over the last months I have to say that I very often heard 
the complaint from (potential) newcomers that they found our coding style (or 
lack thereof) confusing. I have to agree! I'm touching pretty much all our 
codebase when fixing bugs or reviewing patches and it's frustrating as hell to 
have a different style in every file, sometimes even within a single file...

> What about the non-core plugins, i.e. those having their own repository?
> Are you planning to reformat those too?

I'd at least mention this to the respective authors. I won't (and can't) 
enforce it on them of course.

> > Personally I'm still for following the KDELibs policy and maybe even
> > extending it a bit. I'll look at the results of using
> > format.config.uncrustify.4_spaces on the PHP plugin on the weekend and
> > will try to make it as pedantic as possible.
> 
> Looking at the kdelibs coding style, I'd suggest to drop the part about
> Qt includes. The Qt5 changes make it much easier to port when you use
> #include <qfoo.h> instead of #include <QtModule/QtClass>.

Yes!

> Another thing which is not documented there: Whitespace around operators
> and parenthesis.

Yep, there are more shortcomings as well, e.g. where to place the member 
initializer lists and how to format them afaiks.

> Otherwise I think the style is ok (I've come to like the
> opening-brace-on-the-same-line style in the past years) and reasonable
> readable.

As said in the other mail: I'm open for suggestions, as long as it's not too 
far from what we are using now and that it's consistent.

Bye
-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20120421/756a5c4c/attachment.sig>