While we all understand that excessive use of ternary operator
may worsen code readability (e.g. nested, multi-line expression),
there are few cases where using it actually improves code
readability. For instance, when a function takes a long list of
arguments out of which one depends on a boolean expression, or
when formatting "yes"/"no" or "on"/"off" values based on a
boolean variable (although one can argue that the latter is a
subset of the former). Just consider alternatives to:
virBufferAsprintf(buf, "<elem>%s</elem>\n", boolVar ? "yes" : "no");
In fact, this pattern occurs plenty in our code. Exempt it from
our "no ternary operators" rule.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Claudio Fontana <cfontana@suse.de>
---
v2 of:
https://listman.redhat.com/archives/libvir-list/2022-July/233150.html
diff to v1:
- Changed wording, as suggested by Daniel.
docs/coding-style.rst | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/docs/coding-style.rst b/docs/coding-style.rst
index bf0a80fbc5..81bd4474f1 100644
--- a/docs/coding-style.rst
+++ b/docs/coding-style.rst
@@ -470,7 +470,9 @@ Pointer comparisons may be shortened. All long forms are okay.
if (!foo) # or: if (foo == NULL)
New code should avoid the ternary operator as much as possible.
-Specifically it must never span more than one line or nest:
+Its usage in basic cases is warranted (e.g. when deciding between
+two constant strings), however, it must never span more than one
+line or nest.
::
@@ -481,6 +483,9 @@ Specifically it must never span more than one line or nest:
char *foo = bar ? bar->baz ? bar->baz->foo : "nobaz" : "nobar";
+ GOOD:
+ virBufferAsprintf(buf, "<element>%s</element>\n", boolVar ? "yes" : "no");
+
Preprocessor
------------
--
2.35.1
On Mon, Jul 25, 2022 at 05:21:37PM +0200, Michal Privoznik wrote: > While we all understand that excessive use of ternary operator > may worsen code readability (e.g. nested, multi-line expression), > there are few cases where using it actually improves code > readability. For instance, when a function takes a long list of > arguments out of which one depends on a boolean expression, or > when formatting "yes"/"no" or "on"/"off" values based on a > boolean variable (although one can argue that the latter is a > subset of the former). Just consider alternatives to: > > virBufferAsprintf(buf, "<elem>%s</elem>\n", boolVar ? "yes" : "no"); > > In fact, this pattern occurs plenty in our code. Exempt it from > our "no ternary operators" rule. > > Signed-off-by: Michal Privoznik <mprivozn@redhat.com> > Reviewed-by: Claudio Fontana <cfontana@suse.de> > --- > > v2 of: > > https://listman.redhat.com/archives/libvir-list/2022-July/233150.html > > diff to v1: > - Changed wording, as suggested by Daniel. > > docs/coding-style.rst | 7 ++++++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/docs/coding-style.rst b/docs/coding-style.rst > index bf0a80fbc5..81bd4474f1 100644 > --- a/docs/coding-style.rst > +++ b/docs/coding-style.rst > @@ -470,7 +470,9 @@ Pointer comparisons may be shortened. All long forms are okay. > if (!foo) # or: if (foo == NULL) > > New code should avoid the ternary operator as much as possible. > -Specifically it must never span more than one line or nest: > +Its usage in basic cases is warranted (e.g. when deciding between > +two constant strings), however, it must never span more than one > +line or nest. > > :: > > @@ -481,6 +483,9 @@ Specifically it must never span more than one line or nest: > > char *foo = bar ? bar->baz ? bar->baz->foo : "nobaz" : "nobar"; > > + GOOD: > + virBufferAsprintf(buf, "<element>%s</element>\n", boolVar ? "yes" : "no"); > + > Preprocessor > ------------ Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
© 2016 - 2024 Red Hat, Inc.