Putting cyrus-future code in CVS. Also, code style

[Wesley Craig]

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