next »

[Geti]

Dacke: we (myself and the people I'm working with at the moment) just find it easier to read a single line conditional with breathing room around it.

Code:

if( ... )
{
   function_call();
}
else
{
   different_function_call();
}

and

Code:

if ( ... )
   function_call();
else
   different_function_call();

both read more easily to me. The delimited version is safer, I agree, and I'd use it in any conditional where there's large blocks of other code between the clauses - but all of us are familiar enough with the syntax that it's second nature to drop in the braces if expanding a one-liner (We haven't had an issue with that kinda of logical error in the year and a bit we've been working on the current game).

If we had a bigger team of less experienced programmers (or programmers who I didn't have personal experience with) then we'd likely change our style guidelines

[rivon]

At least use this (the ifs and elses always starting a new line, no }else{ ):

Code:

if (...)
{
    // foo
}
else if (...)
{
    // bar
}
else
{
    // lol
}

[Dacke]

That looks absolutely appalling to me. So incredibly spread out for no good reason.

[rivon]

What about good readability? I'm not saying to always use brackets, but when you DO USE brackets, then this style offers the best readability.

[InfiniteStateMachine]

Yeah I would prefer the readability. Especially with the huge screens of today.

I guess ultimately it depends who you are working with. If it's with a new coder I would err on the side of readability to avoid silly bugs down the road.

I'm fine changing styles and don't find any particular style offensive outside of a shitload of ternary if's and obvious attempts to make compact code at the cost of comprehension in some sort of attempt to show off.

[frosty]

I created a HaXe preprocessor called Snax, that I used in the most recent Ludum Dare.  It uses whitespace for formatting and has a framework for rapid prototyping.

You can see the source here:
http://www.fleacircusgames.com/c!ph3r/cipher.snax

(the game is here)

Worked out pretty well, but still has some issues before I'd feel confident to release it.  

[Geti]

That looks absolutely appalling to me. So incredibly spread out for no good reason.

The alternative looks worse to me One of those "each to their own" cases I guess.

[Fallsburg]

At least use this (the ifs and elses always starting a new line, no }else{ ):

Code:

if (...)
{
    // foo
}
else if (...)
{
    // bar
}
else
{
    // lol
}

and I would go:

Code:

if (...){
    // foo
}
else if (...){
    // bar
}
else{
    // lol
}

[Overkill]

When using braces, I mostly put the brace on their own line, and indent the lines between the braces.

Code:

if(cond)
{
    statements;
}
else if(cond)
{
    statements;
}
else
{
    statements;
}

Also, I basically never put whitespace after keywords if there is a parenthesized expression required directly after the keyword.

Nowadays, I have come around to occasionally using brace-on-the-same-line. Particularly, I do this in JavaScript, because it becomes sort of nasty to write some of the annoying define-a-function-literal-and-call-it stuff to fudge around the terrible variable scope issues in the language.

Code:

var funk = (function(lib) {
    lib.foo = function() {
       if(thing) {
          ...
       } else {
          ...
       }
    }
    ...
    return lib;
})({});

If I were to prefer a language syntax, I would say that I want something that is easily machine readable, human readable, explicit, and parses the same regardless of whitespace formatting.


C-like languages have some annoying syntax problems particularly the "dangling else" problem. Here's some shoddy psuedo-BNF:

Code:

if_statement: 'if' '(' expression ')' statement ('else' statement)?
compound_statement: '{' statement* '}'
statement: if_statement | compound_statement | ...

Since the braces are optional, you get ambiguous cases in stuff like:

Code:

if(foo) if(bar) statement; else statement;

Does the 'else' bind to the inner if, or the outer if? It's not entirely clear to everyone. The resolution is to bind 'else' to the nearest if statement, but certainly it makes parsing more difficult, if you use a parser-generator.


This is why Lua gets my vote.

It has a very simplistic syntax, with a fairly low number of keywords and operators. Semi-colons are optional empty-statements to improve readability, but are not required. Newlines are also not required. There is no magical statement completion, like languages like JavaScript. Blocks have unambiguous 'end' delimiters, so this avoids the 'dangling else' problem that C languages have.

List and dictionary initializers use the same syntax -- because in Lua, there is one type, the table that mixes both types.

Unlike Python, you are free to use whitespace as you wish to make things more clear (although indentation is still generally recommended), without having to add syntactic noise to indicate "split this across multiple lines" or "put these related statements on the same line".

Unlike C, and like Python, you assignment is a statement, not an expression -- making a certain category of typos (accidentally using = instead of ==) impossible.  They also don't clog up the language with unnecessary assignment syntax shorthands you see in most languages, like: for increments (++), decrements (--), and other in-place calculations (/=, *=, <<=, etc).

In Lua, unlike Python, local scoping is made explicit (undeclared variables are global lookups), and any block may shadow local declarations in an outer block, and can pass variables in outer scope as an upvalue to closures in a reliable way. Unlike JavaScript or Python, variable declarations are lexically scoped to blocks, instead of function-scoped. Unlike JavaScript's rules for global-fallback, you can actually change the lexical environment of a block to another table which is used instead of the globals table -- allowing you to reliably sandbox pieces of code from using insecure functions, or to prevent namespace pollution.

Python is also very nice, but I am often annoyed by the parsing complexities caused by using indentation as a block delimiter. Also, the fact that function syntax is sort of messed up -- there isn't really *good* syntax for anonymous functions aside from lambdas -- nested functions just feel really wonky, especially the variable scoping rules for them. I guess I just prefer explicit keywords.

Anyways.

[Dacke]

What about good readability? I'm not saying to always use brackets, but when you DO USE brackets, then this style offers the best readability.

I really don't agree you, you see

To me, the readability drops like a stone if you put all the {'s on their own rows. It puts focus on the curly braces instead of the actual code. I want the if-clause to be directly linked to what it does, not have to skim through extra lines of meaning-less curly braces.

If you don't put the left-curlies on their own rows, the code reads more like Python, which is a good thing to me.

[TheLastBanana]

I agree with Dacke on this. I find that there's much more of a flow to reading the code when the curly braces are on the same lines. In my opinion, at least, code is much easier to understand when related statements and expressions are bunched together, so it follows naturally that you'd want to keep curly braces from separating related chunks. You could certainly argue that it's less readable because things are more condensed, but I find it's a reasonable tradeoff for code which feels more logically sorted.

To each his own, though! Obviously there are people who feel the exact opposite way.

[eyeliner]

I don't think I can program without the curlies anymore.

I use a mix of same line curly braces for really short lines of code for debugging (that will not last long), and a single line for each curly when things get a bit longer/final code.

I find them weird dangling at the end of a line, so I always move them to the next.

[sigfarter]

Code:

if(success == true){
    print("You win!");
    score = 1000;
}else{
    print("Oh no, you lost.");
    score = 0;
}
quit();

[sigfarter]

Looks like it could be game of the year.

[moi]

needs more braces, DENTAL PLAN