"Steven Schveighoffer" <schvei...@yahoo.com> wrote in message news:op.vdm3e1fbeav...@localhost.localdomain... > On Wed, 02 Jun 2010 16:50:05 -0400, Alex Makhotin <a...@bitprox.com> > wrote: >> >> I prefer ANSI(Allman) style(second example, wrong). >> They want to force Java-like style which I dislike much. > > I do too. You will not find me using go until they change this. >
This is something I've probably given *way* too much thought to. First of all, my style is generally like this: void foo(int num, bool doBigLoop) { if(num < 7) writeln("Under 7"); if(doBigLoop) foreach(int x; 0..10) // Don't do this "stacking" often, foreach(int y; 0..10) // but it's handy once in a while. if(x+y < 9) { writefln("Under 9"); if(num == x) writefln("num == x"); } } I never liked having the opening and closing curly braces not line up. Just bugs me. Makes it slightly harder to read too. And even harder still if "} else {" is used. I *really* don't like that, when it's used, half the time I don't even see the "else". But, at the same time, the opening-brace-alone-on-it's-own-line often seems like a real waste that (visually) stretches the code out needlessly. So, for a language like D, I just use the '{'-on-a-separate-line style and just deal with the extra line since it seems to be the lesser of the evils. Sometimes it helps readability with long functions anyway. Now, I was happy with that for a long time, but now that I'm learning and loving a lot of functional-like stuff, I'm more and more coming across situations like this: void funcWithLongHeader(SomeTempl!int alpha, SomeTempl!int beta, SomeTempl!int gamma, SomeTempl!int delta, int SomeTempl!epsilon = epsilonDefault) { auto foo = [["a":1, "b":2, "c":3], ["z1":0, "z2":7, "z3":4], ["hi":5, "b":3, "c":3]]; if(alpha + beta == 0 || beta + gamma == 3 || gamma + delta == 6 || alpha = beta + gamma) { writeln("Whee"); whatever(); } someHighOrderFunc((int i) { if(i==77) return 1; else return i; }); } Obviously I have to add some newlines in there, but how should I do it? I could stay consistent with my curly-brace usage: void funcWithLongHeader ( SomeTempl!int alpha, SomeTempl!int beta, SomeTempl!int gamma, SomeTempl!int delta, int SomeTempl!epsilon = epsilonDefault ) { auto foo = [ ["a":1, "b":2, "c":3], ["z1":0, "z2":7, "z3":4], ["hi":5, "b":3, "c":3] ]; if ( alpha + beta == 0 || beta + gamma == 3 || gamma + delta == 6 || alpha = beta + gamma ) { writeln("Whee"); whatever(); } someHighOrderFunc ( (int i) { if(i==77) return 1; else return i; } ); } The arrays look ok. The lambda looks maybe a bit too spread out. The rest looks like crap. I could do this: void funcWithLongHeader( SomeTempl!int alpha, SomeTempl!int beta, SomeTempl!int gamma, SomeTempl!int delta, int SomeTempl!epsilon = epsilonDefault) { auto foo = [ ["a":1, "b":2, "c":3], ["z1":0, "z2":7, "z3":4], ["hi":5, "b":3, "c":3] ]; if(alpha + beta == 0 || beta + gamma == 3 || gamma + delta == 6 || alpha = beta + gamma) { writeln("Whee"); whatever(); } someHighOrderFunc( (int i) { if(i==77) return 1; else return i; } ); } That looks a little better, but there's still some issues. The closing parenthesis on the function header and the if statement are difficult to see. Also, terms in the if conditional are all misaligned now, and in a way that can't be solved in a cross-editor way without eliminating all tabs (which shows a blatant disregard for other people's indentation preferences), or using a very careful, deliberate and brittle mix of spaces and tabs. Also, that now introduces an annoying bit of inconsistency: some grouping symbols start at the end of a line, and others exist on a newline. Parts of it look very Java-style, and other parts look very non-Java-style. So at this point, I can't help thinking: Why not just take the plunge and go 'always-at-the-end-of-the-line' all the way? And while I'm at it, I'll put the closing-parenthesis at the start of a new line, just like a closing curly-brace: void funcWithLongHeader( SomeTempl!int alpha, SomeTempl!int beta, SomeTempl!int gamma, SomeTempl!int delta, int SomeTempl!epsilon = epsilonDefault ) { // snip if( alpha + beta == 0 || beta + gamma == 3 || gamma + delta == 6 || alpha = beta + gamma ) { writeln("Whee"); whatever(); } // snip } Eeeww!!! Also, note that I haven't even tossed call-chaining or templates into the mix. So at this point, I'm convinced that there is no ideal indentation style for C/D/Java-style languages. So what about different languages? If you adopt a LISP-like style, you could have vertically-aligned-braces and also omit the useless "opening curly brace" line: { if(x+y < 9); whatever(); } But that places much more visual emphasis on the '{' than the 'if', which IMO is completely backwards since the 'if' is much more important. In other words, too hard to read. And the weird alignment of the 'if' compared to the 'whatever' is, well...weird. There's another C-derived natively-compiled language out there (I forget what it's called) that has a rather interesting approach. It just simply doesn't use (or even allow, AIUI) an opening brace: if(x+y < 9) whatever(); } It introduces a certain lack of symmetry, and maybe could cause parsing problems for certain things (ex, D2-style template constraints probably wouldn't work, at least not as-is), but it solves the other problems. Although the approach doesn't really scale to parenthesis. There's BASIC/Perl-style keyword approaches: if BLAH then whatever end if if(BLAH) whatever fi These also have the added bonus of avoiding the following unreadable crap that probably every C/D/Java-style programmer is all too familiar with: } } } } } } But of course, this approach is annoyingly verbose, especially in the case of BASIC (why should the ending keywords of a block be more verbose then the starting keyword? just seems pointless and unbalanced). And the Perl-style approach doesn't scale particularly well to other constructs (such as 'while' or user-defined constructs). Then there's the Python approach. But all I'm going to say about that is: Those who dislike it already know why they dislike it, and those who do like it have probably already heard all the complaints before. The only conclusion I can come up with is that all syntaxes suck ;)