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