[Development] [docs] changing the way overloads are documented and presented
Samuel Gaist
samuel.gaist at edeltech.ch
Fri Apr 28 11:24:42 CEST 2017
> On 28 Apr 2017, at 09:35, Marc Mutz <marc.mutz at kdab.com> wrote:
>
> Hi.
>
> TL;DR: I propose to document overloaded functions with a single comment block,
> containing multiple \fn's and a common documentation text, to be rendered as
> one documentation block preceded by a listing of all the \fn's, instead of as
> individual functions.
>
> Since I learned that a qdoc comment block can contain multiple \fn statements,
> I have tried to use it to document overloads with less duplication. E.g.:
>
> /*!
> \fn bool QStringView::startsWith(QStringView str, Qt::CaseSensitivity cs) const
> \fn bool QStringView::startsWith(QLatin1String l1, Qt::CaseSensitivity cs)
> const
> \fn bool QStringView::startsWith(QChar ch) const
> \fn bool QStringView::startsWith(QChar ch, Qt::CaseSensitivity cs) const
>
> Returns \c true if this string-view starts with string-view \a str,
> Latin-1 string \a l1, or character \a ch, respectively;
> otherwise returns \c false.
>
> If \a cs is Qt::CaseSensitive (the default), the search is case-sensitive;
> otherwise the search is case-insensitive.
>
> \sa endsWith(), qStartsWith()
> */
>
> instead of
>
> /*!
> \fn bool QStringView::startsWith(QStringView str, Qt::CaseSensitivity cs) const
>
> Returns \c true if this string-view starts with string-view \a str;
> otherwise returns \c false.
>
> If \a cs is Qt::CaseSensitive (the default), the search is case-sensitive;
> otherwise the search is case-insensitive.
>
> \sa endsWith(), qStartsWith()
> */
>
> /*!
> \fn bool QStringView::startsWith(QLatin1String l1, Qt::CaseSensitivity cs)
> const
>
> Returns \c true if this string-view starts with Latin-1 string \a l1;
> otherwise returns \c false.
>
> If \a cs is Qt::CaseSensitive (the default), the search is case-sensitive;
> otherwise the search is case-insensitive.
>
> \sa endsWith(), qStartsWith()
> */
>
> /*!
> \fn bool QStringView::startsWith(QChar ch) const
>
> Returns \c true if this string-view starts with character \a ch;
> otherwise returns \c false.
>
> The search is case-sensitive.
>
> \sa endsWith(), qStartsWith()
> */
>
> /*!
> \fn bool QStringView::startsWith(QChar ch, Qt::CaseSensitivity cs) const
>
> Returns \c true if this string-view starts with character \a ch;
> otherwise returns \c false.
>
> If \a cs is Qt::CaseSensitive, the search is case-sensitive;
> otherwise the search is case-insensitive.
>
> \sa endsWith(), qStartsWith()
> */
>
> And that's just startsWith(). QString::contains() current has 8,
> QString::arg() has 14, not counting the 8 additional multi-arg() overloads.
>
> Each of them contains mostly the same text. It's a long time since I had to
> consult QString documentation, but I guess for users, this is as hard to read
> as it is for us to write. Sure. cut-n-paste gives you fast initial results.
> But fear the day when you have to make a change to all of the contains()
> documentation blocks, and be it just for adding a missing hyphen.
>
> So, I hear you say, if qdoc already supports multiple \fn in one comment
> block, why don't you just use it.
>
> This is where http://bugreports.qt.io/browse/QTBUG-60420 comes in.
>
> Currently, any content in a multi-\fn block pertains to all functions
> designated by an included \fn, with no way to change. The initial example,
> e.g., copies the text, which is clearly written to refer to the overload set,
> not any particular funciton, verbatim for each of the four functions. As a
> consequence of this, it also throws warnings about invalid \a references.
>
> So, name the parameters the same in every overload...
>
> That works as long as all overloads were added in the same Qt release,
> because, as I said, all content, and thus \since, pertains to all \fn's. IOW:
> you cannot represent the fact that one overload was added in a later Qt
> version.
>
> What I would like to see is something more akin to the presentation in
> cppreference.com. Before you shout: no, I don't like the numbered listing of
> all overloads followed dumbly by a numbered listing of documentation for each
> overload. What I like is the numbered listing of the overloads, followed by
> free-form text, as in the initial example. It's up to the individual
> documentation writer and his reviewers to avoid falling into a
> cppreference.com-style of itemised text. I think that the initial example is
> an elegant way of how to document that particular set of overloads without
> having to refer to any of them in particular.
>
> I would like to see a multi-\fn comment block (and only those) transformed
> into a multi-function block in the documentation, too, first listing all the
> functions designated by the \fn's, with \since, \obsolete, ... attached to a
> function (like in cppreference.com, following the signature, in parentheses),
> not the whole block, followed by the free-form block.
>
> Naturally, there'd need to be a way to reference any particular overload. This
> could be done with a \label added to each function, or just a number: \1, \2,
> referring to their position in the listing of \fn's.
>
> This would probably shrink the length of the QString and QStringView page by
> more than half, and, if we would add \until into the mix, would allow to
> represent even complicated cases like QSharedPointer::create() very naturally:
>
>
> \fn QSharedPointer::create()
> \since 5.1
> \until 5.7
> \fn QSharedPointer::create(const Arg &arg)
> \since 5.4
> \until 5.7
> \fn QSharedPointer::create(Args &&...args)
> \since 5.4
>
> <docs>
>
> Overload \3 requires C++11, which used to be optional. When Qt made support
> for C++11 a requirement in 5.7, overloads \1 and \2 were dropped, since \3
> can represent them.
>
> Rendered as:
>
> 1. QSharedPointer<T> QSharedPointer::create() [static] (since 5.1)
> (until 5.7)
> 2. QSharedPointer<T> QSharedPointer::create(const Arg &arg) [static] (since 5.4)
> (until 5.7)
> 3. QSharedPointer<T> QSharedPointer::create(const Arg &arg) [static] (since 5.4)
>
> <docs>
>
> Overload (3) requires ...
>
> What do you think?
>
> Thanks,
> Marc
>
> --
> Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
> KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
> Tel: +49-30-521325470
> KDAB - The Qt, C++ and OpenGL Experts
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
Hi,
+1
I think it’s a pretty good idea. That will make the documentation more concise which isn’t a bad thing when looking for overloads.
Samuel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170428/b358e3d2/attachment.sig>
More information about the Development
mailing list