Getting Style

[Aleix Pol]

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.

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 :)

Aleix