Let's end the formatting mess

[Milian Wolff]

On Thursday 10 November 2011 16:17:52 David Nolden wrote:
> 2011/11/10 Milian Wolff <mail at milianw.de>:
> > Yes, finally! I totally agree in that we need a consistent style
> > everywhere. Personally I like the two spaces as well, but wouldn't care
> > too much about four spaces either.
> > 
> > But: The "real" next step before actually reformatting everything is to
> > find a style we all follow. As we are a KDE project, I personally vote
> > for: http://techbase.kde.org/Policies/Kdelibs_Coding_Style
> > 
> > 1) This makes it easy for people to contribute to KDE, as they just need
> > to
> > remember one style. And many developers are already acquainted with that
> > style.
> > 
> > 2) It is already documented, we don't need to sit down and define what
> > want
> > others to do.
> > 
> > 3) It is "proven", i.e. many people work with it and it works well for
> > them.
> > 
> > 4) It is near to the Qt-coding style, i.e. see again 1).
> 
> However, it would be a big change, and I don't really like it. For
> example, I prefer spaces between function-calls, and I prefer the "*"
> adjacent to the type name as we have now. We already have some quite
> commonly used styles, I think we should simply make everything
> consistent by picking a style which is consistent, but minimizes the
> changes required to the code when reformatting it, thus minimizing the
> pain for us. Our project is large enough to have an own style.

Enforcing a coding style we cannot take "I don't like it" into account. For 
every style there will be people having objections against something (e.g. 
formatting).

And considering that we already need to reformat huge parts, I don't see an 
issue with doing it right, and doing it just once. Sure, it will touch huge 
parts, but at least we have a long list of advantages later on.

The "we are large enough, we can have our own style" is a nice statement, but 
has no value. There is no advantage, only disadvantages, of having our own 
style.

> > 5) There is even an astyle config for it.
> 
> Uncrustify does much more extensive reformatting though, and thus is
> more suitable to enforce a consistent coding style. Also we need to
> use a commandline utility, so that KDevelop can also be developed with
> another IDE/editor.

I'm not arguing against uncrustify as the preferred choice. I'm just saying 
that with this we could use astyle as well (at least for the stuff it 
supports). And astyle is also just a cli utility, or what am I missing here?

> > Which brings me to the second part: Having a reformat-all guideline is
> > nice
> > and useful. But to actually enforce this we could need two things:
> > 
> > a) proper in-editor "on-the-fly" formatting. This is actually a long
> > standing feature request, and a very important one.
> > 
> > b) a pre-commit hook that compares checked-in-file VS reformatted
> > checked-in- file. If they differ, it rejects the file. This would of
> > course require work from our beloved KDE BOFHs which are always pretty
> > busy. Most probably one of us would need to sit down and get this hook
> > implemented. I reason this would be very useful for other projects as
> > well.
> > 
> > Both are imo important but could / should be done after we agreed on a
> > proper style. If we start to enforce a proper style - even if only
> > manually - for new code, we won't have much work later. But it still
> > won't prevent our codebase from getting messy again. The two points
> > above, esp. the hook, are required to get this done.
> 
> These things are very useful, but are not required right from the
> start. A step forward stays a step forward, we can still remember each
> other to reformat the source properly. It is naive anyway to believe
> that a script alone can make our formatting perfect, there are things
> that even uncrustify doesn't fix (for example naming conventions), so
> the developers will stay responsible anyway, we're just making it
> easier.

Yes, of course. Exactly my musings I tried to summarize in the last paragraph 
above. I just hope we get there eventually.

> >> And another thing: What is the sense of all the kate modelines around?
> >> It seems like kate inherits these options just fine from the source
> >> files, so the modelines aren't required.
> > 
> > Kate has no ability to "guess" the code style from a file, the modelines
> > are required. But the preferred way is to put them into a project file
> > (search for .kateconfig).
> 
> The whole kate configuration is redundant with the source-formatter
> configuration though, so we should get rid of this, and derive the
> settings from the formatter config.

Yes but that requires work on Kate to be able to read/write the editor 
settings. Which is not yet possible, but another long standing wish request.

bye
-- 
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/20111110/7b08c534/attachment.sig>