On Wed, 2016-09-28 at 10:04 +0100, Daniel P. Berrange wrote:
We do *not* apply
a strict 80 character limit in libvirt.
Is that so? I was under the impression that we did, mostly
due to the fact that long lines are often pointed out
during review, but turns out that in fact the HACKING file
mentions no such rule.
There are some hints of encouraging, if not enforcing,
lines that do not exceed 80 columns, like
if (expr)
die("a diagnostic that would make this line"
" extend past the 80-column limit"));
or the sample invocation of indent(1) using the '-l75
-lc75' arguments. Plus the prohibit_long_lines rule that's
enforced as part of syntax-check
# Long lines can be harder to diff; too long, and
# git send-email chokes.
# For now, only enforce line length on files where
# we have intentionally
# fixed things and don't want to regress.
sc_prohibit_long_lines:
(a)prohibit='.{90}' \
in_vc_files='\.arg[sv]' \
halt='Wrap long lines in expected output files' \
$(_sc_search_regexp)
(a)prohibit='.{80}' \
in_vc_files='Makefile\.am' \
halt='Wrap long lines in Makefiles' \
$(_sc_search_regexp)
but is limited to a small number of non-C files.
Personally, I find the 80-column limit a pointless vestige
of long gone days; moreover, trying to enforce that limit
leads to code that is noticeably harder to read and wastes
more than 50% of the typical developer's monitor width.
Can we agree on something more reasonable, like 100 columns,
and document it / try to actually enforce it? From a cursory
look, it seems like we're 90% of the way there anyway.
--
Andrea Bolognani / Red Hat / Virtualization