Getting Style

[Sven Brauch]

I have encountered those problems too. It doesn't really have fancy
rules how to threat that ":" operator...

> sp_inside_paren=add
yes, that does that, but it will also turn "foo(3)" into "foo( 3 )",
which I personally hate. It does have an option to add the spaces only
for if / for / while, but they don't work correctly (if the expression
in the if ends with a closing paren, no space will be added).
Your suggestion sufferes from a similar issue, btw. It will do
"foo(3)", but "foo( bar(3) )", which makes no sense in my opinion. Why
add spaces only if the inner statement ends with a paren? I find it
very inconsistent, and I didn't yet find a way to change this
behaviour.
Did you intend to do it like this?

Greetings

Am 21. April 2012 16:30 schrieb Milian Wolff <mail at milianw.de>:
> On Saturday 21 April 2012 16:21:26 Milian Wolff wrote:
>> On Saturday 21 April 2012 09:41:27 Andreas Pakulat wrote:
>> > On 21.04.12 04:45:46, Milian Wolff wrote:
>> > > On Friday 20 April 2012 21:44:14 Andreas Pakulat wrote:
>> > > > On 20.04.12 19:29:31, Milian Wolff wrote:
>> > > > > # 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.
>> > >
>> > > From my experience over the last months I have to say that I very often
>> > > heard the complaint from (potential) newcomers that they found our
>> > > coding
>> > > style (or lack thereof) confusing. I have to agree! I'm touching pretty
>> > > much all our codebase when fixing bugs or reviewing patches and it's
>> > > frustrating as hell to have a different style in every file, sometimes
>> > > even within a single file...
>> >
>> > I see, well if it helps attracting contributors thats certainly a strong
>> > argument to do it in the case of kdevelop.
>> >
>> > I guess I'm also a bit biased since I'm paid to work on code and hence
>> > cannot really say "nah this has messed up formatting, I won't touch it".
>> > Instead I just fix the formatting around the area I work in.
>> >
>> > > > Otherwise I think the style is ok (I've come to like the
>> > > > opening-brace-on-the-same-line style in the past years) and reasonable
>> > > > readable.
>> > >
>> > > As said in the other mail: I'm open for suggestions, as long as it's not
>> > > too far from what we are using now and that it's consistent.
>> >
>> > For coming up with a good style, I'd say it would be good to create an
>> > example cpp file which contains all kinds of formattable things. Then
>> > format it according to your liking and create uncrustify rules for that.
>> > Present that to the group and let the ranting begin :P At least thats
>> > how I created the formatting for our Java codebase, since I seldomly
>> > understand what exactly the options are affecting and which different
>> > cases..
>>
>> Yep, agreed. But I already found some severe issues with uncrustify... Seems
>> like we'll have to patch it first to make our usecase feasable. I've found
>> no way to properly layout this code e.g.:
>
> <snip>
>
> Another example that breaks:
>
>
> class a
> {
>    Q_OBJECT
>    Q_INTERFACES(KDevelop::ILanguageSupport)
> public:
>    explicit LanguageSupport( QObject* parent, const QVariantList& args =
> QVariantList() );
> };
>
> ->
>
>
> class a
> {
>    Q_OBJECT
>    Q_INTERFACES(KDevelop::ILanguageSupport)
>
> public
>        : explicit LanguageSupport( QObject* parent, const QVariantList& args
> = QVariantList() );
> };
>
> --
> Milian Wolff
> mail at milianw.de
> http://milianw.de
>
> --
> KDevelop-devel mailing list
> KDevelop-devel at kdevelop.org
> https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
>