Getting Style

[Milian Wolff]

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

class A : public B, C
{
public:
  explicit A(int a, int b);
};

A::A(int a, int b)
: B(a)
, C(b)
{
}

the only options I found trigger output like this:

class A
  : public B
  , C
{
public:
  explicit A(int a, int b);
};

A::A(int a, int b)
  : B(a)
  , C(b)
{
}

Which would be OK with me but not as nice, esp. the break/indentation of the 
base classes...

Furthermore, formatting something like this:

MyLongNS::FooBar::Asdf someLongFuncName(int a, int b,
                                        int c, int d)
{
}

becomes

MyLongNS::FooBar::Asdf someLongFuncName(int a, int b,
    int c, int d)
{
}


Which is also pretty ugly but I didn't find the proper alignment option yet...

You can my uncrustify config so far here:

http://paste.kde.org/461006/


-- 
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/3e73a0f4/attachment.sig>