httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Richards <p.richa...@elsevier.co.uk>
Subject Re: your mail
Date Mon, 01 Jul 1996 15:52:25 GMT
Ben Laurie writes:
 > Paul Richards wrote:
 > > 
 > > Anymore comments?
 > 
 > Indents should be 4 not 8 spaces...

I've explicitly stated that.  I tend to like using tabs, it makes it
much quicker to indent to new levels but I have had my tabs set to 4
for quite a few years so I agree with the indentation level. As long as
indentation at the end of lines is done with spaces the tabstop doesn't
actually make much difference. You obviously have a tabstop of 8 which is
why you're seeing that level of indentation.

 > > /* Enum types are capitalized. */
 > > enum enumtype { ONE, TWO } et;
 > 
 > There is no consensus for this, and, furthermore, it isn't currently done 
 > this way...

Well, no-one's voted on this at all. It's still an open issue. How things
are currently done doesn't really matter much since a lot of re-formatting
will have to be done when this is nailed down.

 > > 	if (test)
 > > 		stmt;
 > > 	else if (bar) {
 > > 		stmt;
 > > 		stmt;
 > > 	} else
 > 
 > The consensus says:
 > 
 > 	}
 > 	else

I'm not convinced it does. Most people just voted a), we need another vote
on whether it was a1 or a2. I'll argue a case for a2. a1 uses more
vertical space and doesn't add anything to the readability. It breaks my
preference about using white space to delineate different functional
levels since there are { chars in the same column as the statements.

When you have

	if .......
		.......
		.......
		.......
	} else {
		.......
		.......
		.......
	}

there is clear space marking the code that is executed in each of the
clauses, with 

	if .......
		.......
		.......
		.......
	}
	else {
		.......
		.......
		.......
	}

it's not as visually clean.

 > > 	/*
 > > 	 * Exits should be 0 on success, and 1 on failure.  Don't denote
 > > 	 * all the possible exit points, using the integers 1 through 300.
 > > 	 */
 > 
 > Why not? OK, for Apache it doesn't matter but for some things it is very
 > useful...

Don't know actually, I was wondering about this myself.

 > > 	(void) fprintf(stderr, "usage: f [-ab]\n");
 > 
 > Inconsistent spacing after a cast.

Well, that's still to be resolved too :-)

Ok a summary of still open issues:

1) Enum types
2) } else clauses
3) Spaces after casts.
4) return and exit clauses

any others?

My position:

1) Having enum types in upper case (and variables in lower case) makes it
clear that an array index is one or the other. Without this distinction you
have to find the declaration in order to establish what it is. There
are similar examples where this distinction applies.

2) see above.

3) The whole point about spacing is readability, conserving
vertical space is to get more code on a single screen but it should not be
at the cost of readability, I personally believe the cases for conserving
vertical space make it more readable by not having lots of hanging braces
on lines of their own (and I've conceded the function layout). Horizontal
space should be used as much as possible so that it's easy to see each
element of the statement, there's no real reason to conserve it since there
are plenty of clean ways to break up a single statement and adding the
odd space here and there doesn't often make lines too long, particularly
with the indentation scheme we intend to use.

4) I think return clauses should use the same style as exit for consistency
of appearance.

Mime
View raw message