Let's end the formatting mess

[David Nolden]

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.

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

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

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

Greetings, David