[Swan-dev] readable C style for split control statements

[D. Hugh Redelmeier]

| From: Andrew Cagney <andrew.cagney at gmail.com>

| On Sun, 30 Sep 2018 at 15:52, D. Hugh Redelmeier <hugh at mimosa.com> wrote:

| > This absolutely brings these statements into conformity with
| > <https://github.com/torvalds/linux/blob/master/Documentation/process/coding-style.rst>
| 
| I couldn't find anything specific?   And when I cut/pasted the
| suggested lisp into my .emacsrc, it hung the second line off the paren
| the way you (and I) prefer.

 		if (!NLMSG_OK(nlhdr, (size_t)readlen) ||
		    nlhdr->nlmsg_type == NLMSG_ERROR)
 			return -1;

In the first section, "Indentation", the second last paragraph:

	Outside of comments, documentation and except in Kconfig,
	spaces are never used for indentation, and the above example
	is deliberately broken.

That should answer your specific question.

The obvious way to conform is to indent the second line one tab, as
Tuomo has done.

 		if (!NLMSG_OK(nlhdr, (size_t)readlen) ||
			nlhdr->nlmsg_type == NLMSG_ERROR)
 			return -1;

In the kernel code that I looked at, this was not commonly done.  So I
think that this rule need not be taken too seriously.

But there is a second, less awful, conforming possibility: indenting
the second line with TWO tabs:

 		if (!NLMSG_OK(nlhdr, (size_t)readlen) ||
				nlhdr->nlmsg_type == NLMSG_ERROR)
 			return -1;

That makes the distinction between the broken line and succeeding
(contained) statements fairly clear.  But it does have a couple of
drawbacks:

- often there is similarity between multiple lines of a conditional,
  and that becomes hard to see when the parts are not aligned.  I find
  that seeing this kind of similarity is often important in my
  understanding code.

- the line is broken because it is long and complicated.  To make it
  most understandable, you want to break in the clearest way.
  Throwing away an extra 12 columns may over-constrain you.

Now I'm going to argue the other side.  But this does not apply to
Libreswan, so you can ignore from here on.

For projects where I get to set the style, I've used only tabs for
indentation and set my editor to display tabs every 4 columns.  Anyone
else can use 8-column tabs and see the identical logical structure.
Of course the lines for them might be quite a bit wider.  This only
works if indentation is ONLY by tabs, not spaces.

Oh, and another difference in my chosen style: when you break a line,
you break it before the operation.  For things like IF, the second
line is not further indented.  FreeS/Wan's Pluto used that style.

 		if (!NLMSG_OK(nlhdr, (size_t)readlen)
		|| nlhdr->nlmsg_type == NLMSG_ERROR)
 			return -1;

At first glance, this looks odd and ugly.  The more you get used to it
the more it makes sense.  The structure becomes completely evident
from reading just the left side of text.  (Like all styles, it fails
if the indentation doesn't actually match the braces etc.  And C
compilers don't generally report when indentation is broken.)

It especially makes sense if the operator at the break is || or &&,
which is usually the case.  These operators are kind of control flow
operators themselves and other control flow things are already at the
left.