From: Markus Armbruster <armbru@redhat.com>
To: "Philippe Mathieu-Daudé" <philmd@redhat.com>
Cc: qemu-trivial@nongnu.org, qemu-devel@nongnu.org,
Stefano Garzarella <sgarzare@redhat.com>,
qemu-riscv@nongnu.org, David Gibson <david@gibson.dropbear.id.au>
Subject: Re: [Qemu-trivial] [Qemu-devel] [PATCH v3 3/3] util/cutils: Move function documentations to the header
Date: Tue, 05 Feb 2019 07:42:49 +0100 [thread overview]
Message-ID: <87a7jaag7q.fsf@dusky.pond.sub.org> (raw)
In-Reply-To: <20190204211204.27321-4-philmd@redhat.com> ("Philippe Mathieu-Daudé"'s message of "Mon, 4 Feb 2019 22:12:04 +0100")
Philippe Mathieu-Daudé <philmd@redhat.com> writes:
> Many functions have documentation before the implementation in
> cutils.c. Since we expect documentation around the prototype
> declaration in headers,
We do?
There are two justifiable function comment placement styles: (1) next to
definition, and (2) next to declaration if it's in a header, else next
to definition.
The rationale for the latter is having the headers do double-duty as
interface documentation.
The rationale for the former is consistently placing the function
comments close to the code gives them a fighting chance to actually
match the code.
I'm in the "next to definition" camp. If you want concise interface
specification, use something like Sphinx.
QEMU code is, as so often, in all camps.
> move the comments in cutils.h.
We document some cutils functions next to their definition, and some
next to their declaration. The inconsistency is ugly, and your patch
fixes it. I'd fix it in the other direction.
Even if we decide to fix this one in this direction, I object to the
sweeping generalization in the commit message :)
WARNING: multiple messages have this Message-ID (diff)
From: Markus Armbruster <armbru@redhat.com>
To: "Philippe Mathieu-Daudé" <philmd@redhat.com>
Cc: qemu-trivial@nongnu.org, qemu-devel@nongnu.org,
Stefano Garzarella <sgarzare@redhat.com>,
qemu-riscv@nongnu.org, David Gibson <david@gibson.dropbear.id.au>
Subject: Re: [Qemu-riscv] [Qemu-devel] [PATCH v3 3/3] util/cutils: Move function documentations to the header
Date: Tue, 05 Feb 2019 07:42:49 +0100 [thread overview]
Message-ID: <87a7jaag7q.fsf@dusky.pond.sub.org> (raw)
In-Reply-To: <20190204211204.27321-4-philmd@redhat.com> ("Philippe Mathieu-Daudé"'s message of "Mon, 4 Feb 2019 22:12:04 +0100")
Philippe Mathieu-Daudé <philmd@redhat.com> writes:
> Many functions have documentation before the implementation in
> cutils.c. Since we expect documentation around the prototype
> declaration in headers,
We do?
There are two justifiable function comment placement styles: (1) next to
definition, and (2) next to declaration if it's in a header, else next
to definition.
The rationale for the latter is having the headers do double-duty as
interface documentation.
The rationale for the former is consistently placing the function
comments close to the code gives them a fighting chance to actually
match the code.
I'm in the "next to definition" camp. If you want concise interface
specification, use something like Sphinx.
QEMU code is, as so often, in all camps.
> move the comments in cutils.h.
We document some cutils functions next to their definition, and some
next to their declaration. The inconsistency is ugly, and your patch
fixes it. I'd fix it in the other direction.
Even if we decide to fix this one in this direction, I object to the
sweeping generalization in the commit message :)
WARNING: multiple messages have this Message-ID (diff)
From: Markus Armbruster <armbru@redhat.com>
To: "Philippe Mathieu-Daudé" <philmd@redhat.com>
Cc: qemu-trivial@nongnu.org, qemu-devel@nongnu.org,
Stefano Garzarella <sgarzare@redhat.com>,
qemu-riscv@nongnu.org, David Gibson <david@gibson.dropbear.id.au>
Subject: Re: [Qemu-devel] [PATCH v3 3/3] util/cutils: Move function documentations to the header
Date: Tue, 05 Feb 2019 07:42:49 +0100 [thread overview]
Message-ID: <87a7jaag7q.fsf@dusky.pond.sub.org> (raw)
In-Reply-To: <20190204211204.27321-4-philmd@redhat.com> ("Philippe Mathieu-Daudé"'s message of "Mon, 4 Feb 2019 22:12:04 +0100")
Philippe Mathieu-Daudé <philmd@redhat.com> writes:
> Many functions have documentation before the implementation in
> cutils.c. Since we expect documentation around the prototype
> declaration in headers,
We do?
There are two justifiable function comment placement styles: (1) next to
definition, and (2) next to declaration if it's in a header, else next
to definition.
The rationale for the latter is having the headers do double-duty as
interface documentation.
The rationale for the former is consistently placing the function
comments close to the code gives them a fighting chance to actually
match the code.
I'm in the "next to definition" camp. If you want concise interface
specification, use something like Sphinx.
QEMU code is, as so often, in all camps.
> move the comments in cutils.h.
We document some cutils functions next to their definition, and some
next to their declaration. The inconsistency is ugly, and your patch
fixes it. I'd fix it in the other direction.
Even if we decide to fix this one in this direction, I object to the
sweeping generalization in the commit message :)
next prev parent reply other threads:[~2019-02-05 6:43 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-04 21:12 [Qemu-trivial] [PATCH v3 0/3] cutils: Cleanup, improve documentation Philippe Mathieu-Daudé
2019-02-04 21:12 ` [Qemu-devel] " Philippe Mathieu-Daudé
2019-02-04 21:12 ` [Qemu-riscv] " Philippe Mathieu-Daudé
2019-02-04 21:12 ` [Qemu-trivial] [PATCH v3 1/3] util/cutils: Move size_to_str() from "qemu-common.h" to "cutils.h" Philippe Mathieu-Daudé
2019-02-04 21:12 ` [Qemu-devel] " Philippe Mathieu-Daudé
2019-02-04 21:12 ` [Qemu-riscv] " Philippe Mathieu-Daudé
2019-02-04 21:12 ` [Qemu-trivial] [PATCH v3 2/3] util/cutils: Move ctype macros " Philippe Mathieu-Daudé
2019-02-04 21:12 ` [Qemu-devel] " Philippe Mathieu-Daudé
2019-02-04 21:12 ` [Qemu-riscv] " Philippe Mathieu-Daudé
2019-02-05 10:32 ` [Qemu-trivial] " Cornelia Huck
2019-02-05 10:32 ` [Qemu-devel] " Cornelia Huck
2019-02-05 10:32 ` [Qemu-riscv] " Cornelia Huck
2019-02-05 10:49 ` [Qemu-trivial] [Qemu-devel] " Daniel P. Berrangé
2019-02-05 10:49 ` Daniel P. Berrangé
2019-02-05 10:49 ` [Qemu-riscv] " Daniel P. Berrangé
2019-02-04 21:12 ` [Qemu-trivial] [PATCH v3 3/3] util/cutils: Move function documentations to the header Philippe Mathieu-Daudé
2019-02-04 21:12 ` [Qemu-devel] " Philippe Mathieu-Daudé
2019-02-04 21:12 ` [Qemu-riscv] " Philippe Mathieu-Daudé
2019-02-05 6:42 ` Markus Armbruster [this message]
2019-02-05 6:42 ` [Qemu-devel] " Markus Armbruster
2019-02-05 6:42 ` [Qemu-riscv] " Markus Armbruster
2019-02-05 10:56 ` [Qemu-trivial] " Peter Maydell
2019-02-05 10:56 ` Peter Maydell
2019-02-05 10:56 ` [Qemu-riscv] " Peter Maydell
2019-02-05 11:04 ` [Qemu-trivial] " Daniel P. Berrangé
2019-02-05 11:04 ` Daniel P. Berrangé
2019-02-05 11:04 ` [Qemu-riscv] " Daniel P. Berrangé
2019-02-05 12:30 ` [Qemu-trivial] " Markus Armbruster
2019-02-05 12:30 ` Markus Armbruster
2019-02-05 12:30 ` [Qemu-riscv] " Markus Armbruster
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87a7jaag7q.fsf@dusky.pond.sub.org \
--to=armbru@redhat.com \
--cc=david@gibson.dropbear.id.au \
--cc=philmd@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-riscv@nongnu.org \
--cc=qemu-trivial@nongnu.org \
--cc=sgarzare@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.