[Swan] initial thoughts on uncrustifying libreswan

Lennart Sorensen lsorense at csclub.uwaterloo.ca
Fri May 24 16:52:51 EEST 2013


On Thu, May 23, 2013 at 01:07:56PM -0400, D. Hugh Redelmeier wrote:
> Agreed.  But weird isn't always wrong.
> 
> Paul likes space on both sides of the "?" operator.  I only want a
> space after the "?", perhaps based on my experience with English.  But
> he's probably right.
> 
> Thinking as I write this: one rationalization of my dislike of the
> space before the "?", even though I like a space either side of the
> corresponding ":", is that the "?" operator isn't semantically
> symmetric while the ":" is.
> 
> Segueing to another topic: redundant parens.  C's operator precedence
> is quite complicated.  Adding redundant parens is good when it reduces
> confusion, but bad when it adds clutter (visually matching parens is
> much harder when there are redundant ones).  The tradeoff really
> depends on the familiarity of the reader with the operator precedence.
> 
> I really dislike redundant parens around the operand of "return".  Yet
> I think that I always use parens in sizeof.

sizeof seems like a function.  return clearly isn't a function.

> Sorry that I wasn't clearer.  I definitely want the opening brace on
> the same line as the head of the control structure.
> 
> This example was meant to illustrate one exception: when the head of
> the control structure is broken across multiple lines, I think that
> putting the opening brace on its own line makes the structure clearer.

I think doing kernel style is clearer:

if (somestuff that is really long and goes on forever
		more stuff that goes on and on and on) {
	code;
	more code;
}

So the continuation is double indented to make it clear it isn't part
of the code block yet.

So it is pretty clear that the block starts with the if... and ends with }
since those are at the same level, and the block contains the two code
lines, since those are one level indented, and the continuation of the
if goes and hides another level down.

> BTW, if one is always using "new style" function definitions (as
> opposed to K&R style), and the function declaration part fits on one
> line, I don't mind the brace being on that line as well.
> 
> Yes, in general.

I don't like exceptions.  It makes rules complicated.

> Len's more radical suggestion is to always brace.  It has some merit.
> I could be convinced.  I wonder how many lines would be added to
> libreswan.  I might get around to measuring that.

I will admit that wanting always braced which adds extra lines seems
to conflict with wanting the opening brace on the same line to reduce
wasted lines.  But it is consistent:  I don't like lines wasted, but I
also don't like bugs caused by a line being added to somewhere that is
missing braces causing the code to behave differently than it appears.

> What are other people's thoughts about always bracing?  By that, I
> mean always using a block within a control statement, even if the
> block has only one statement?
> 
> 	if (something) {
> 		action;
> 	}
> 
> Perhaps related: I noticed that uncrustify left some statements of
> this form:
> 
> 	if (something) action;

I hate those.  Seems popular in perl, but just not a good idea.

> or worse
> 	for (...) ;

That usually results in hard to understand code.  Yuck.

> I would ALWAYS break this into two lines.
> 
> 
> Another point: the ";" as an empty statement is fairly invisible.  It
> really only comes up as the body of FOR or WHILE statements.  I've
> played at making it more visible.
> 
> - in FOR and WHILE, I think Henry used to use "continue;" instead of ";".
>   I don't quite like that since continue is a kind of control-flow
>   exception.
> 
> - I've sometimes used "{}".  This is implied by Lennart's "always
>   brace" rule, but I happened to put both braces on the same line.
>   This is an argument in favour of "always brace" because it
>   eliminates this as a special case.

Hmm.  To some extent I think the part before the braces with a while
is for condition checks, not for doing work.  No reason you couldn't
put the work in the braces instead, and leave the condition check only.
Yeah it adds a line or two, but is generally more readable.  The generated
code by the compiler is almost certainly going to be the same either way.
Some people do think they are smarter than the compiler though. :)

> Do you have opinions on this?

I am sure everyone has at least one opinion, sometimes more.


-- 
Len Sorensen


More information about the Swan mailing list