On 28 Jun 2010, at 21:35, Bron Gondwana wrote:
HASH || DASH
Agreed. Spacing around double bars is correct IMHO.
HASH|DASH
And no sparcing around single bars. I'm happy with that.
I'd say space around | and ||, both.
Similarly, space around mathematical operators.
Yeah.
Personally, I always include the brace, with the exception of one-
liners, e.g.:
if ( foo ) goto blah;
I think that's a better approach too, but there's HEAPS of code in
Cyrus at the moment that's not that way. If we decide to say
"unless it's on the same line it has braces" then I'm happy to
say that and start making all new code follow it.
I'd say this is an area that warrants a change.
How do you feel about:
if (a) function_one(a);
else function_two();
I think lack of braces reduces vertical space at the code of clarity,
so I'd add the braces. I don't see a bunch of examples, but there
are definitely a few. I wouldn't go back and change them in
otherwise working code. I've definitely noted cases of what
otherwise looks like a naked "else" in the code. There are also
examples of:
} else {
}
else {
and probably every other possible combination. So defining "what's
there" can be a challenge.
* goto is permitted within a function only
As opposed to long jump? My rule for thumb for goto's is:
1) to the end of a function for cleanup
2) occasionally, to the top of a loop, but only if using another
control structure is *less* clear
That's how it's used within Cyrus now. I would like to keep that
"allowed" by the coding standard.
This is as opposed to "goto is not allowed"? I agree, "goto is
allowed", in cases where the code is made more clear by its use.
:wes
