Commit Graph

22 Commits

Author SHA1 Message Date
Jiri Denemark
d317d1d217 docs: Document requirements on format strings in translated messages
Preserving the order of format strings (%s, ...) when translating
messages may be very hard or even impossible depending on the target
language. On the other hand, reordering them requires understanding the
C-format strings which is not something we should expect from
translators. And even if someone reorders format strings in the right
way (by addressing arguments directly using N$), someone else may use a
translation tool that requires format strings in msgid and msgstr to
match exactly and forces these correct formats to be reverted.

As a result of this, we had several reported crashes in some locales
because integers were formatted as strings. So to make such crashes less
likely to happen and to make translating our messages easier, we now
require all messages that are marked for translation to use format
strings that always refer to the same argument no matter where they
appear in a message (e.g., %1$s, %5$llu).

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2023-04-01 11:40:31 +02:00
Michal Privoznik
059e096435 internal: Introduce STRCASESKIP()
There is so far one case where STRCASEPREFIX(a, b) && a +
strlen(b) combo is used (in virVMXConfigScanResultsCollector()),
but there will be more. Do what we do usually: introduce a macro.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Tim Wiederhake <twiederh@redhat.com>
2022-11-16 12:15:05 +01:00
Michal Privoznik
af4b994bc4 docs: Fill missing docs on STRCASEPREFIX() and STRSKIP()
We document use of our STR*() macros, but somehow missed
STRCASEPREFIX() and STRSKIP().

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Tim Wiederhake <twiederh@redhat.com>
2022-11-16 12:15:03 +01:00
Michal Privoznik
f396ac5af4 coding-style: Follow our own recommendation wrt spacing around commas
We require a space after a comma and even document this in our
coding style document. However, our own rule is broken in the
very same document when listing string comparison macros.
Separate macro arguments properly.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Tim Wiederhake <twiederh@redhat.com>
2022-11-16 12:14:54 +01:00
Michal Privoznik
32b9d4390e coding-style: Allow some use of ternary operators
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>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2022-07-26 08:48:48 +02:00
Michal Privoznik
9e8601c464 lib: Use G_NO_INLINE instead of G_GNUC_NO_INLINE
The G_GNUC_NO_INLINE macro will eventually be marked as
deprecated [1] and we are recommended to use G_NO_INLINE instead.
Do the switch now, rather than waiting for compile time warning
to occur.

1: 15cd0f0461
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
2022-07-18 17:23:15 +02:00
Tim Wiederhake
6c68f120a5 docs: coding-style: One variable declaration per line
This was not mentioned before.

Signed-off-by: Tim Wiederhake <twiederh@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
2022-01-19 14:54:08 +01:00
Tim Wiederhake
95c380d410 docs: coding-style: Clarify on virXXXPtr types
This partially reverts commit 9ccbed6afb.

Signed-off-by: Tim Wiederhake <twiederh@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
2022-01-19 14:54:08 +01:00
Tim Wiederhake
c807f65de6 docs: coding-style: Remove "no_memory" as acceptable goto target
There are no instances of that label left.

Signed-off-by: Tim Wiederhake <twiederh@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2022-01-17 10:59:19 +01:00
Tim Wiederhake
15ca9bf2bc docs: coding-style: Rewrite section on shortening comparisons
The code style showed `bool hasFoos; if (hasFoos == true)` as a
good example in one place, only to warn against comparisons with
`true` a couple of paragraphs further down.

Merge this advice on comparing with `true` into the "Conditional
expressions" section and split the example up for readability.

Signed-off-by: Tim Wiederhake <twiederh@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2022-01-17 10:58:59 +01:00
Michal Privoznik
c8238579fb lib: Drop internal virXXXPtr typedefs
Historically, we declared pointer type to our types:

  typedef struct _virXXX virXXX;
  typedef virXXX *virXXXPtr;

But usefulness of such declaration is questionable, at best.
Unfortunately, we can't drop every such declaration - we have to
carry some over, because they are part of public API (e.g.
virDomainPtr). But for internal types - we can do drop them and
use what every other C project uses 'virXXX *'.

This change was generated by a very ugly shell script that
generated sed script which was then called over each file in the
repository. For the shell script refer to the cover letter:

https://listman.redhat.com/archives/libvir-list/2021-March/msg00537.html

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
2021-04-13 17:00:38 +02:00
Michal Privoznik
9ccbed6afb coding-style: Don't encourage virXXXPtr typedefs
We don't like virXXXPtr typedefs really and they are going away
shortly, possibly. Do not encourage new code to put in the
typedefs.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2021-03-16 09:15:40 +01:00
Peter Krempa
d380dd0efd util: virstring: Remove virStrncpy
The function is now unused and motivated users to write crazy parsers
which were hard to understand, had pointless error paths just to avoid
few memory allocations.

Remove the function as we're fine with g_strndup and virStrcpy.

Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2021-03-12 10:57:42 +01:00
Tim Wiederhake
03be543f6b docs: Fix dead link
Signed-off-by: Tim Wiederhake <twiederh@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
2021-01-05 11:25:14 +01:00
Michal Privoznik
5f6a761899 coding-style: Document 100 chars limit for line length
The idea is to have it like a soft limit: if possible then break
lines, if not then have a long line instead of some creative
approach.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-12-02 16:36:01 +01:00
Michal Privoznik
da20178709 docs: Document camelCase preference for XML elements and attributes
Recently I've merged a patch that used hyphens in an attribute
name. I fixed it later, but turned out we don't document our
preference which is camelCase.

Suggested-by: Erik Skultety <eskultet@redhat.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
2020-10-19 10:18:27 +02:00
Peter Krempa
931c1d128d syntax-check: Don't forbid curly braces around single line condition body
This syntax rule doesn't make much sense, especially if there are so
much exceptions to it. Just remove it and adjust the coding style.

Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2020-09-15 15:20:23 +02:00
Michal Privoznik
95b9db4ee2 lib: Prefer WITH_* prefix for #if conditionals
Currently, we are mixing: #if HAVE_BLAH with #if WITH_BLAH.
Things got way better with Pavel's work on meson, but apparently,
mixing these two lead to confusing and easy to miss bugs (see
31fb929eca for instance). While we were forced to use HAVE_
prefix with autotools, we are free to chose our own prefix with
meson and since WITH_ prefix appears to be more popular let's use
it everywhere.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2020-09-02 10:28:10 +02:00
Ján Tomko
6fab37da59 Prefer https: everywhere where possible
Use https: links for websites that support them.

The URIs which are used as namespace identifiers
are left alone.

Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Neal Gompa <ngompa13@gmail.com>
2020-09-01 21:58:46 +02:00
Laine Stump
866bb99644 docs: point out that locals should be defined at the top of a block of code
Although we have nothing in make syntax-check to enforce this, and
apparently there are places where it isn't the case (according to
Dan), we should discourage the practice of defining new variables in
the middle of a block of code.

https://www.redhat.com/archives/libvir-list/2020-July/msg00433.html

Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
2020-07-10 13:42:42 -04:00
Andrea Bolognani
f42be8a2ef docs: Use definition list instead of table in coding style
This format is much easier to tweak and update.

Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-05-11 13:55:25 +02:00
Andrea Bolognani
5155f6f4b1 docs: Add coding-style.rst
This part represents the biggest chunk of the existing hacking.rst, and
despite that its utility is very limited because 'make syntax-check'
already guarantees most of the rules are followed over time.

Until the glorious day we finally codify our coding style completely
into a configuration for a tool such as clang-format and thus no longer
need a plain English description of it, move this part to a separate
page.

Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-04-08 09:32:30 +02:00