Getting Style

[Milian Wolff]

On Saturday 21 April 2012 02:01:52 Sven Brauch wrote:
> Hi,
> 
> To raise that question again: Do you also want to apply that to
> external plugins?
> 
> If not, I'm not very comfortable with the way kdevelop / kdevplatform
> code is currently formatted anyways, so I'm okay with any change. :)

As said just in the mail to apaku: I won't enforce it, but I will suggest it 
to the respective authors. It just makes it easier to go from one code base to 
the other, if you need help from us e.g. or when you plan to incorporate your 
plugin into kdeveop/kdevplatfrom in the future.

> Am 20. April 2012 22:20 schrieb David Nolden
> 
> <david.nolden.kdevelop at art-master.de>:
> > Am 20. April 2012 21:44 schrieb Andreas Pakulat <apaku at gmx.de>:
> >> 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.
> > 
> > The main benefit of reformatting, to me, is making it easier to write
> > consistently formatted code in different parts of KDevelop. With
> > correct format_sources rules in place, KDevelop would use the correct
> > indentation settings wherever I am, and I could fixup my code to be
> > formatted perfectly using a single keystroke.
> > 
> > Greetings, David
> > 
> > --
> > KDevelop-devel mailing list
> > KDevelop-devel at kdevelop.org
> > https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
-- 
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/d8e6d279/attachment.sig>