The big problem there is really Xcode. It’s woeful for text handling. Just try and paste any random block of text in, and see what it gives you; different results from line-to-line. It’s always been that way. Do not get me started on the ill-conceived “line everything up with colons” idiocy of some years back…

Of course, posting destroyed my indentation! Imagine spaces before the statements between guard and else, and spaces before the statements bewtween the {}. guard, else, and {} are all at the same indent.

Allmän style is definitely the correct style. All this nonsense about putting the opening brace at the end of the line with the keyword is nonsense and it really annoys me that you have to fight Xcode to do it right. One of the few areas in which Eclipse is superior IMO is the power of the code formatting tools which allow you to choose almost any brace formatting style you like.

Actually no. I once attended a course that was given by Steve McConnell and at the end, as a light hearted question, we asked him about how to do the braces. His opinion is that a space in hell is reserved for One True Brace Style (how can anybody pretend that “} else {” is anything but horrible) but Allman style was not far behind.

Well, you know what they say about opinions… I’ve been using my current style for over 20 years, modifying it to suit languages and IDEs and the practicalities of reading/writing code. Appeals to authority aren’t going to change that. I’m open to constructive ideas about programming, but not dogma or ideas-from-authority. People have different needs: I prefer to read AND write code that looks as much like English as possible. (And thus look at functional programming fashions like diseases of language.)

My code excerpts didn’t come out as intended. They were supposed to have conditions between the if and else, and between the guard and { }, and have “do stuff” code between the { }. YAMF = Yet Another Markup Failure.

I agree with losing the else keyword. Also, it would be nice if there would be a way, if optionally/default desired. to somehow eliminate the “exit” statement in the else clause if with an some modification of the guard keyword which would provide an implicit exit. That way, Imo, the else clause (where the else keyword would also be gone) would be much easier to visually scan and type for many situations.

I think the behavior would be less completely obvious at a glance without the “else”, that tells your eyes right away that the attached clause is what executes if the conditions *aren’t* all true, so I can understand why it’s there; though I feel like that may only be necessary because “guard” itself fails to do that. Maybe they could have gone with, say, “unless” rather than “guard”, leaving out the “else” but otherwise being semantically identical.

I use Adrian’s formation quite often, especially for short length statements. I also tend to do similar things with switch statements with the addition of tabbing the code executed to the same column. As an aside, the Pascal “case” statement is better than the switch statement Imo, since each case doesn’t need a keyword.