From: "Philippe Mathieu-Daudé" <philmd@redhat.com>
To: "Marc-André Lureau" <marcandre.lureau@redhat.com>, qemu-devel@nongnu.org
Cc: "Peter Maydell" <peter.maydell@linaro.org>,
"Daniel P . Berrangé" <berrange@redhat.com>
Subject: Re: [PATCH] RFC: CODING_STYLE: describe "self" variable convention
Date: Wed, 20 Nov 2019 17:05:20 +0100 [thread overview]
Message-ID: <bb4b636d-99d0-4fbe-c4bb-ec3d5c480a03@redhat.com> (raw)
In-Reply-To: <20191120125444.31365-1-marcandre.lureau@redhat.com>
On 11/20/19 1:54 PM, Marc-André Lureau wrote:
> Following the discussion in thread "[PATCH v3 13/33] serial: start
> making SerialMM a sysbus device", I'd like to recommend the usage of
> "self" variable to reference to the OOP-style method instance, as
> commonly done in various languages and in GObject world.
>
> Cc: Peter Maydell <peter.maydell@linaro.org>
> Cc: Daniel P. Berrangé <berrange@redhat.com>
> Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
> ---
> CODING_STYLE.rst | 38 ++++++++++++++++++++++++++++++++------
> 1 file changed, 32 insertions(+), 6 deletions(-)
>
> diff --git a/CODING_STYLE.rst b/CODING_STYLE.rst
> index 427699e0e4..cb6635af71 100644
> --- a/CODING_STYLE.rst
> +++ b/CODING_STYLE.rst
> @@ -102,12 +102,38 @@ Rationale:
> Naming
> ======
>
> -Variables are lower_case_with_underscores; easy to type and read. Structured
> -type names are in CamelCase; harder to type but standing out. Enum type
> -names and function type names should also be in CamelCase. Scalar type
> -names are lower_case_with_underscores_ending_with_a_t, like the POSIX
> -uint64_t and family. Note that this last convention contradicts POSIX
> -and is therefore likely to be changed.
> +Variables are lower_case_with_underscores; easy to type and read.
> +
> +The most common naming for a variable is an abbreviation of the type
> +name. Some common examples:
> +
> +.. code-block:: c
> +
> + Object *obj;
> + QVirtioSCSI *scsi;
> + SerialMM *smm;
> +
> +When writing QOM/OOP-style function, a "self" variable allows to refer
> +without ambiguity to the instance of the method that is being
> +implemented (this is not very common in QEMU code base, but it is
> +often a good option to increase the readability and consistency,
> +making further refactoring easier as well). Example:
> +
> +.. code-block:: c
> +
> + serial_mm_flush(SerialMM *self);
> +
> + serial_mm_instance_init(Object *o) {
> + SerialMM *self = SERIAL_MM(o);
> + ..
> + }
> +
> +Structured type names are in CamelCase; harder to type but standing
> +out. Enum type names and function type names should also be in
> +CamelCase. Scalar type names are
> +lower_case_with_underscores_ending_with_a_t, like the POSIX uint64_t
> +and family. Note that this last convention contradicts POSIX and is
> +therefore likely to be changed.
>
> When wrapping standard library functions, use the prefix ``qemu_`` to alert
> readers that they are seeing a wrapped version; otherwise avoid this prefix.
>
So in this example:
static void pci_unin_agp_init(Object *obj)
{
UNINHostState *s = UNI_NORTH_AGP_HOST_BRIDGE(obj);
SysBusDevice *sbd = SYS_BUS_DEVICE(obj);
PCIHostState *h = PCI_HOST_BRIDGE(obj);
/* Uninorth AGP bus */
memory_region_init_io(&h->conf_mem, OBJECT(h),
&pci_host_conf_le_ops,
obj, "unin-agp-conf-idx", 0x1000);
memory_region_init_io(&h->data_mem, OBJECT(h),
&pci_host_data_le_ops,
obj, "unin-agp-conf-data", 0x1000);
object_property_add_link(obj, "pic", TYPE_OPENPIC,
(Object **) &s->pic,
qdev_prop_allow_set_link_before_realize,
0, NULL);
sysbus_init_mmio(sbd, &h->conf_mem);
sysbus_init_mmio(sbd, &h->data_mem);
}
You would change 'Object *obj' -> 'Object *self'?
But here we want to keep 'klass', right?
static void gpex_host_class_init(ObjectClass *klass, void *data)
{
DeviceClass *dc = DEVICE_CLASS(klass);
PCIHostBridgeClass *hc = PCI_HOST_BRIDGE_CLASS(klass);
hc->root_bus_path = gpex_host_root_bus_path;
dc->realize = gpex_host_realize;
set_bit(DEVICE_CATEGORY_BRIDGE, dc->categories);
dc->fw_name = "pci";
}
Maybe we should restrict 'self' as name of Object type only?
But your example is with SerialMM, so no?
next prev parent reply other threads:[~2019-11-20 16:06 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-20 12:54 [PATCH] RFC: CODING_STYLE: describe "self" variable convention Marc-André Lureau
2019-11-20 16:05 ` Philippe Mathieu-Daudé [this message]
2019-11-20 16:24 ` Alex Bennée
2019-11-20 16:39 ` Marc-André Lureau
2019-11-20 16:35 ` Marc-André Lureau
2019-11-20 16:55 ` Philippe Mathieu-Daudé
2019-11-20 17:00 ` Daniel P. Berrangé
2019-11-20 17:37 ` Marc-André Lureau
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=bb4b636d-99d0-4fbe-c4bb-ec3d5c480a03@redhat.com \
--to=philmd@redhat.com \
--cc=berrange@redhat.com \
--cc=marcandre.lureau@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).