On Tuesday 01 December 2015 22:36:52 Alex Merry wrote: > On 2015-12-01 15:34, Martin Walch wrote: > > On Saturday, November 14, 2015 06:08:55 PM Alex Merry wrote: > >> On 2015-11-14 01:21, Martin Walch wrote: > >> > Alright, so I have created a stub at > >> > > >> > https://techbase.kde.org/Policies/Frameworks_Coding_Style > >> > > >> > ... > >> > > >> > Qt includes > >> > * For Qt #includes omit the module name and only use the class name. > >> > >> These are all still applicable. > > > > Does the same pattern apply to Frameworks includes? > > For example: > > > > KFileItem instead of KIOCore/KFileItem > > and > > KIO/HostInfo instead of KIOCore/KIO/HostInfo > > > > and of course not something like kfileitem.h or kio/hostinfo.h > > Yes, although good luck trying to explain that, given the inconsistency > between <KIO/HostInfo> and <KFileItem>
This is not inconsistent at all. The first one is about the class KIO::HostInfo, the second one is about the class KFileItem. The header file is consistent with the class that it defines. > <KIOCore/KFileItem> is only > possible by fluke, really, as a side effect of where we install the > version headers. Well it's the same as <QtCore/QCoreApplication>, i.e. an include that starts with the module name. But for the same reasons as in Qt, this is not recommended. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
