[Libreoffice] LibreOffice Code Cleanup Patch

[Lubos Lunak]

On Friday 27 of January 2012, Muthu Subramanian K wrote:
> Hello Alexander,
>
> Its nice to see those patches. But, it will be nice to see/use the
> tools/scripts directly? Especially if they can be hooked to git (like
> the current white space/tabs removal ones)?

 Are you seriously suggesting that we get git hooks that will automatically do 
code formatting? That is such a huge barrel of worms that I don't want even 
to guess what people would complain about the most. You can't compare that to 
the existing hooks, whose results are pretty much a no-op in practice - I'd 
hate it if git decided to actually alter the code under my hands during every 
commit, and I don't think I'd be the only one.

 BTW, according to what rules would that formatting work? I don't know if 
there's actually any document on LO's code style, I think there's only one 
from OOo times (which I'd hope people don't want to cling to so much, given 
that it encourages some stuff that's so old that even jokes about it are 
obsolete).

> @lubos: Alexander is good with scripts, so as a starter he wanted to do
> something like
> "http://cgit.freedesktop.org/libreoffice/core/commit/?id=59cefd339d0c3fcde5
>b614d7f142a957397672d9" . So, yes, I had asked him to give it a shot. I
> guess, the patch is good as well?

 The patch itself is well, but as I said, I think it is not worth even the 
small nuisance this causes with git blame. It makes sense to e.g. fix code 
formatting, because inconsistent indentation is awful to read, but I find it 
rather pointless to do anything about a space that does not matter at all, 
since it is a purely cosmetic change and it is perfectly readable both ways.

 If Alex is good with scripts, he'd be more than welcome to e.g. use them to 
change writer's cryptic indentifiers to something that does not need 
decyphering. Which would affect git blame as well, but in this case the huge 
increase in readability of the code would be more than worth it. Tasks for 
new contributors should be easy, but they should preferably be also useful.

-- 
 Lubos Lunak
 l.lunak at suse.cz