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: @prohibit='.{90}' \ in_vc_files='\.arg[sv]' \ halt='Wrap long lines in expected output files' \ $(_sc_search_regexp) @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 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list