[Swan] initial thoughts on uncrustifying libreswan

D. Hugh Redelmeier hugh at mimosa.com
Thu May 23 20:07:56 EEST 2013


| From: Richard Guy Briggs <rgb at tricolour.net>

| On Thu, May 23, 2013 at 10:28:22AM -0400, Lennart Sorensen wrote:
| > On Thu, May 23, 2013 at 03:43:54AM -0400, D. Hugh Redelmeier wrote:

| > > - when an expression is broken by an newline, normally at a binary
| > >   operator, put the operator at the start of the new line.
| > > 
| > >   This makes the structure of the program evident by scanning
| > >   only indentation and the leftmost token on a line.
| 
| This is an unusual convention, but it completely makes sense to me and I am
| willing to support it.  It doesn't look so odd for logical and/or, but it does
| look weird for the comma operator.

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.

| > >   In the case of control expressions for IF, WHILE, etc.
| > >   the new line should be indented the same as the start of the
| > >   statement.
| > > 
| > > 	if (blah blah blah
| > > 	&& yack yack yack)
| > > 	{
| > > 		/* open brace is on its own line in this case */
| > > 	}
| 
| This is one of the few places I diverge with DHR.  I strongly prefer the
| starting brace on the same line, with the exception of top level braces in a
| file (funciton, struct and global definitions).

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.

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.

| > I also hate opening braces being on their own line.  Waste of screen
| > space. :)
| 
| I'm with Len on this.

Yes, in general.

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.

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;

or worse
	for (...) ;

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.

Do you have opinions on this?


More information about the Swan mailing list