Getting Style

[Milian Wolff]

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
-------------- 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/87b0985a/attachment.sig>