Kdelibs Coding Style vs. preparations for Qt5

[Albert Astals Cid]

El Dissabte, 29 de desembre de 2012, a les 10:48:48, Kevin Ottens va escriure:
> Hello,
> 
> On Saturday 29 December 2012 02:47:13 Friedrich W. H. Kossebau wrote:
> > --- 8< ---
> > Qt Includes
> > 
> > If you add #includes for Qt classes, use both the module and class name.
> > This allows library code to be used by applications without excessive
> > compiler include paths.
> > 
> > Example:
> > // wrong
> > #include <QString>
> > 
> > // correct
> > #include <QtCore/QString>
> > --- 8< ---
> > From http://techbase.kde.org/Policies/Kdelibs_Coding_Style#Qt_Includes
> 
> Since I've been skimming quite a bit through kdelibs codebase recently,
> needless to say this rule is in practice void as it's clearly not followed.
> 
> > Of course the current Qt Coding Style, which is the base of the kdelibs
> > one, does not mention anything about that, given that its about their own
> > headers.
> 
> Yep.
> 
> > Now the Porting from Qt 4 to Qt 5 guide from KDAB recommends this:
> > --- 8< ---
> > Fixing up includes
> > 
> > [...]
> > 
> > Or more portably (Which works in Qt 4 and Qt 5):
> > #include <QWidget>
> > --- 8< ---
> > From http://www.kdab.com/porting-from-qt-4-to-qt-5/
> > 
> > 
> > So what to do about this?
> 
> I *personally* prefer the fully qualified style with the module name. That
> said, since we don't have per module namespaces to go with it and the like
> it's rather cosmetic more than anything. Now add to that the fact that the
> fully qualified style will generate more work when you port (for classes
> moving from one module to another) it sounds like it's the right move to
> drop them completely and use only the class name for includes[*].
> 
> > Will kde-frameworks be Qt5-only, so not need to support both Qt4 and Qt5
> > and thus to use module-less Qt includes?
> 
> For now it supports both, but it's very likely that by the end of january it
> will be Qt5 only.
> 
> > Or will the includes be if-def'ed? So will projects which refer to the
> > Kdelibs Coding Style need to add an exception to their rules for the
> > includes, if they want to prepare for Qt5?
> > 
> > Or does the rule need adaption?
> 
> With what I wrote above I think the natural conclusion is to adapt the rule.
> We should push to use the class name only includes I think.
> 
> Also, contributing to Qt itself more, I noticed some differences in style
> between both (namely: we ignore space around operators, and we for braces
> around single line statements). Your question makes me wonder if we should
> update our own KDE Frameworks style to be closer of the Qt one. The aim here
> would be to be consistent accross the whole stack.
> 
> Actually looking at both documents now, I see we should already follow the
> spacing around operators today... I think the intent of our coding style was
> to be "the Qt style with extra exceptions" but somewhere in the wording
> this gets lost. Maybe we should do a better job at it... If we go toward
> being closer to the Qt style maybe the proper way out would be to shorten
> the document quite a bit saying: use the Qt style + includes section +
> astyle section + emacs & vim section. Right now by duplicating some but not
> all of the Qt style we're diluting the messaging it seems. Opinions?
> 
> Thanks for bringing it up though, it's definitely the right time for that.

Would there be any chance to have the style check done by a pre-commit hook?
Or at least have a command-line tool that checks it for me?

Personally I find it is quite hard to remember all the different coding styles 
of the bazillion projects I controbiute to and since i can't remember they in 
my head i have to find the page that describes the coding style and check it 
manually each time i want to contribute to the respective projects, and to be 
honest that is quite boring and lowers my morale.

Cheers,
  Albert

> 
> Regards.
> 
> PS: Please, before hitting reply think twice! This type of thread can easily
> degenerate in bikeshedding. So put your personal preferences at the door as
> I tried to, it's really not the point.
> 
> PPS: My PS might sound obvious and unneeded to some of you, but I got burnt
> enough times with coding styles discussions to be extra cautious now. It's
> really easy to loose perspective and I might end up doing the mistake
> myself, the reminder is for me too. :-)
> 
> [*] Note that, History might prove me wrong there at some point if Qt6
> introduces classes with the same name in different modules... if that's the
> case I hope it'll come with consistent namespacing though. :-)