Things To Look Out For In Reviews: Difference between revisions

From Qt Wiki
Jump to navigation Jump to search
(Includes.)
(Add section on canons.)
Line 4: Line 4:


This page is a low-entry-bar staging area for potential project-wide guidelines. After each release, we should go over each of these and decide whether we keep them here, or, preferably, fold them into [[Review Policy]], [[API Design Principles]], [[Commit Policy]], [[Qt Coding Style]], [[Coding Conventions]] or a new or existing QUIP.
This page is a low-entry-bar staging area for potential project-wide guidelines. After each release, we should go over each of these and decide whether we keep them here, or, preferably, fold them into [[Review Policy]], [[API Design Principles]], [[Commit Policy]], [[Qt Coding Style]], [[Coding Conventions]] or a new or existing QUIP.
= Canons =
Be aware of the following generally-accepted principles:
* [https://community.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B KDE Binary Compatibilty Page] (a must-read, must-understand for anyone doing API reviews)
* [https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines CppCoreGuidelines] (a lot of stuff of doubtful quality in there these days, but if you get an F.3 comment, that's where to find what that means)
* [[API Design Principles]]
* [[Commit Policy]]
* [[Qt Coding Style]]
* [[Coding Conventions]]


= Newly-Added Things =
= Newly-Added Things =

Revision as of 16:49, 9 January 2024


This page is a low-entry-bar staging area for potential project-wide guidelines. After each release, we should go over each of these and decide whether we keep them here, or, preferably, fold them into Review Policy, API Design Principles, Commit Policy, Qt Coding Style, Coding Conventions or a new or existing QUIP.

Canons

Be aware of the following generally-accepted principles:

Newly-Added Things

When adding a new Thing, don't forget to provide rationale.

Public Headers

Includes

  • Include Qt headers always as <QtModule/qheader.h>. Rationale: it's probably the fastest way to include the file while maintaining compatibility with non-per-module-include build systems.
  • Group includes in descending specificity / ascending generality: first, module headers, then dependenee Qt modules, then QtCore headers, then C++ headers, then C headers, then platform / 3rd-party headers. Separate groups with blank lines. In each group, sort alphabetically. Rationale: Like in CMakeLists's SOURCES, or removed_api.cpp, or tests, ordering code minimizes conflicts between independent changes.

Enums

New Classes

  • Make sure new (value) classes follow the draft value-class mechanics QUIP-22.
  • Documentation:
    • Is the documentation for the class complete and in good shape (grammar, style, correctness)?
    • Is the class documented as new with \since?
    • Does the class provide a good overview section?
    • Is it properly linked from related API and overview documentation? In particular, check whether similar or related classes have any \ingroup commands and whether it makes sense the class should also have it!
    • Should the class be mentioned in the What's New in Qt 6 overview documentation?

Polymorphic Classes

Deprecated and Removed Things

  • Does the documentation reflect the deprecation, and mention the version it is first deprecated for (see also qdoc's \deprecated command? Does it give the user a rationale, as well as a suggestion for alternatives?

Decided To Keep Here

(make a proper subsection grouping when moving stuff here)