Getting Style

[Milian Wolff]

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.sh

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

-- 
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/20120420/cb5d1d12/attachment.sig>