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
signature.asc
Description: This is a digitally signed message part.
