Getting Style

[Milian Wolff]

On Friday 20 April 2012 19:40:34 Aleix Pol wrote:
> On Friday 20 April 2012 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.
> > 
> > # keeping the style consistent
> > 
> > Just now I sat down and investigated git pre-commit hooks, and wrote this:
> > 
> > https://github.com/milianw/shell-helpers/blob/master/uncrustify_stylecheck
> > .s h
> > 
> > Assuming we reformat all our sources, then we just need to tell every
> > contributor to add the above commit-hook to his kdev* git checkouts. Then
> > as soon as he tries to commit some bad change (i.e. uncrustify finds a
> > difference), he will get output like this:
> > 
> > http://paste.kde.org/460586/
> > 
> > And as you can see, his commit was canceled. If he was *really* sure this
> > is a false-positive, just add "-n" to the git commit message and the
> > commit goes in anyways. This will be useful for commits to the stable
> > branches since we probably don't want to reformat them as well.
> > 
> > In the future, I'd like to see this hook also on the server somewhere,
> > such
> > that contributors that did not configure this pre-commit hook get a nice
> > error message as well.
> > 
> > # remember, kdevelop integration!
> > 
> > Once we have this setup for all our repos, we can also tell our users how
> > to setup KDevelop when hacking on KDevelop such that our generated
> > sources always follow the correct guidelines, using the format_sources
> > script from David.
> > 
> > # 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. The question is just:
> > What style do we use?
> > 
> > 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.
> > 
> > Cheers
> 
> IIRC, the outcome was that it wasn't really worth. Also there was quite an
> intense discussion regarding spacing and all.

Let us then please use this discussion to decide whether to do the formatting 
or not. As far as I can see, David and me are pro and the others are "doesn't 
have to be, but OK if you want to do it". So +2 :)

> Personally, even if I think that using a standard is good (as everybody else
> I think) I don't feel very comfortable with the kdelibs format (which I
> proposed in the past, ironically).
> 
> I'm unsure about all this, but I'm open to ideas :)

Cheers
-- 
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/1e42dd08/attachment.sig>