Kdelibs Coding Style vs. preparations for Qt5

[Kevin Ottens]

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.

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. :-)
-- 
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud patron of KDE, http://www.kdab.com
-------------- 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/kde-core-devel/attachments/20121229/b51cf8bd/attachment.sig>