Page 1 of 2

Braces vs indent vs "end ..." syntax preference

Posted: Wed Nov 26, 2014 2:18 am UTC
by Thesh
Braces:

Code: Select all

if condition
{ //Insert preferred brace style here, but keep it to yourself
    statement1
    statement2
    statement3
}


Indent:

Code: Select all

if condtion
    statement1
    statement2
    statement3


end...

Code: Select all

if condition
    statement1
    statement2
    statement3
end if


Spoiler:
After years of going back and forth between the first two and disliking the third because of verbosity, I finally accepted number three, as long as there is no "then" - either parens (C style) or colons (python style, preferred) because "then" adds nothing. My main reasoning is when you have nesting that goes beyond the screen it becomes so much more readable, and you don't have to screw around trying to line up indents.

Re: Braces vs indent vs "end ..." syntax preference

Posted: Wed Nov 26, 2014 8:18 am UTC
by karhell
I typically go for indent style, if only because it forces some coherence in the code's structure.

That said, you make a good argument for the 'end...' syntax being good for particularly long blocks (and absolutely agreed, 'then' is a bloody useless keyword)

Re: Braces vs indent vs "end ..." syntax preference

Posted: Wed Nov 26, 2014 9:19 am UTC
by azule
All three combined, but second one being for style not mandatory.

Re: Braces vs indent vs "end ..." syntax preference

Posted: Wed Nov 26, 2014 9:33 am UTC
by lorb
You did indent all 3 examples. I think just by that fact indent wins clearly. No one likes code like this: (braces or end)

Code: Select all

if condition
{ //Insert preferred brace style here, but keep it to yourself
statement1
if condition
{ // see above
statementa
statementb
}
statement2
statement3
}

Re: Braces vs indent vs "end ..." syntax preference

Posted: Wed Nov 26, 2014 9:50 am UTC
by azule
Nope, it doesn't. You really don't want to rely on invisible whitespace.

Re: Braces vs indent vs "end ..." syntax preference

Posted: Wed Nov 26, 2014 10:42 am UTC
by Xenomortis
Braces with indent.

Re: Braces vs indent vs "end ..." syntax preference

Posted: Wed Nov 26, 2014 11:23 am UTC
by lorb
azule wrote:Nope, it doesn't. You really don't want to rely on invisible whitespace.


Whitespace is invisible but indent-level is not.

Re: Braces vs indent vs "end ..." syntax preference

Posted: Wed Nov 26, 2014 11:44 am UTC
by azule
Unless there are spaces equivalent to the width of the indent. Is this indenting all in tabs or spaces? I still think there is chance of mixup. Plus there's wrap around indenting done in some editors.

Re: Braces vs indent vs "end ..." syntax preference

Posted: Wed Nov 26, 2014 1:05 pm UTC
by karhell
azule wrote:Unless there are spaces equivalent to the width of the indent. Is this indenting all in tabs or spaces? I still think there is chance of mixup. Plus there's wrap around indenting done in some editors.

which is precisely why python3 requires sticking to (tabs XOR spaces) for indent level.

Re: Braces vs indent vs "end ..." syntax preference

Posted: Wed Nov 26, 2014 1:38 pm UTC
by Xenomortis
karhell wrote:which is precisely why python3 requires sticking to (tabs XOR spaces) for indent level.

Does it allow spaces for alignment?

Re: Braces vs indent vs "end ..." syntax preference

Posted: Wed Nov 26, 2014 1:58 pm UTC
by lorb
azule wrote:Is this indenting all in tabs or spaces?

Besides the point that tabs vs spaces is a different holy war, does it matter what that whitespace is made of? All modern editors can automatically interchange tabs for spaces or the other way round, whatever you prefer.

Re: Braces vs indent vs "end ..." syntax preference

Posted: Wed Nov 26, 2014 2:04 pm UTC
by karhell
Yep, no problem. Space or tab is only important when it comes to indentation. Alignment is entirely up to you. I'll try to dig up something more formal to support that claim

Re: Braces vs indent vs "end ..." syntax preference

Posted: Wed Nov 26, 2014 6:57 pm UTC
by azule
No one said what language this should be for. Is indent only for python?

I've used all 3 types in different coding languages, but only brackets in any major capacity. When you guys say "indent" you're not saying space and/or tabs? See, I'm confused now. How do you align the code without a space or a tab?

Re: Braces vs indent vs "end ..." syntax preference

Posted: Thu Nov 27, 2014 8:32 am UTC
by karhell
azule wrote:No one said what language this should be for. Is indent only for python?

I've used all 3 types in different coding languages, but only brackets in any major capacity. When you guys say "indent" you're not saying space and/or tabs? See, I'm confused now. How do you align the code without a space or a tab?

I've heard of other languages that use indentation as part of their syntax, python-style (mars, for example). Pretty sure that's what the "indent" option means : languages that define blocks by their indentation level (via tabs and/or spaces) instead of braces, begin..end statements... etc.

As an aside, I've just noticed it is actually possible to mix whitespace characters in python3, tabs are just expanded to n spaces (still not a good reason to do so, IMO)
python lexical analysis wrote:Firstly, tabs are replaced (from left to right) by one to eight spaces such that the total number of characters up to and including the replacement is a multiple of eight

Re: Braces vs indent vs "end ..." syntax preference

Posted: Thu Nov 27, 2014 8:44 am UTC
by EvanED
karhell wrote:As an aside, I've just noticed it is actually possible to mix whitespace characters in python3, tabs are just expanded to n spaces (still not a good reason to do so, IMO)
python lexical analysis wrote:Firstly, tabs are replaced (from left to right) by one to eight spaces such that the total number of characters up to and including the replacement is a multiple of eight
You'll note it also says -- in the Python 3 versions -- "Indentation is rejected as inconsistent if a source file mixes tabs and spaces in a way that makes the meaning dependent on the worth of a tab in spaces; a TabError is raised in that case." There is also a switch to Python 2 to make it behave that way. At least AFAIK, this makes the "expands to 8 characters" specification unimportant; I suspect that only matters when reporting column numbers in stack traces and similar if it does that. (I forget if it does, though I don't think so.)

----

My answer is braces. I went into Python with an open mind about the whitespace-sensitivity, and even liked it for a time, but I have come out after a while preferring explicit markers. I don't like the verboseness of the "end if" style markers. Occasionally that's useful -- e.g. you sometimes see "} // if" -- but I think most of the time it would be useful, you would want more information than just "this is the end of the if" to make things clearer, e.g. a comment summarizing the condition or what is being iterated over.

Re: Braces vs indent vs "end ..." syntax preference

Posted: Thu Nov 27, 2014 7:23 pm UTC
by Thesh
I really don't like the optional nature of braces, because it leads to programming errors (see the goto fail exploit, granted that there were a lot of other issues that led to that). Whitespace and "end..." based scoping don't have that problem. Putting the braces at the end of thee control flow operator saves whitespace, but makes it less obvious that the code is in braces, and putting it on the next line (my preference) does waste whitespace, especially when you have a lot of indentation. "end..." forces you to follow a single style, leaving out brace style wars/inconsistencies, while also taking up equal or less whitespace than most brace styles.

I also really don't like switches in C.

This is inconsistent with the rest of the code, and just looks wrong:

Code: Select all

switch (a) {
case 1:
    //something
    break;
case 2:
    / /something else
    break;
default:
    //yet another thing
}


This is excessive indentation:

Code: Select all

switch (a) {
    case 1:
        //something
        break;
    case 2:
        / /something else
        break;
    default:
        //yet another thing
}


This is just right:

Code: Select all

switch a:
case 1:
    //something
    break;
case 2:
    / /something else
    break;
default:
    //yet another thing
end switch

Re: Braces vs indent vs "end ..." syntax preference

Posted: Thu Nov 27, 2014 7:55 pm UTC
by ahammel
Braces, mostly because it's easy for an editor to indent them correctly.

Re: Braces vs indent vs "end ..." syntax preference

Posted: Thu Nov 27, 2014 7:59 pm UTC
by Thesh
ahammel wrote:Braces, mostly because it's easy for an editor to indent them correctly.


If they are optional, then there's not really much of a difference because they still have to recognize keywords and therefore implement basically the same code to recognize control statements.

Re: Braces vs indent vs "end ..." syntax preference

Posted: Thu Nov 27, 2014 8:29 pm UTC
by ahammel
Thesh wrote:
ahammel wrote:Braces, mostly because it's easy for an editor to indent them correctly.


If they are optional, then there's not really much of a difference because they still have to recognize keywords and therefore implement basically the same code to recognize control statements.
The difference is that you don't have to cycle through indent levels.

Edit: also it's not possible to reliably automatically indent blocks of code if indentation level is significant. Haskell mode in emacs just disables block indentation, for instance.

Re: Braces vs indent vs "end ..." syntax preference

Posted: Fri Nov 28, 2014 3:29 pm UTC
by markfiend
I'm agnostic about the other two options but I cordially detest "end..." syntax.

Re: Braces vs indent vs "end ..." syntax preference

Posted: Fri Nov 28, 2014 6:08 pm UTC
by LambdaBeta
Personally, I can't stand tab bracing, because sometimes I want to drop my indenting for a good reason. For example:

Code: Select all

#include <stdio.h>
int showHelp()
{
    printf("\
help [-h] -- Displayes this help message.\n\
    -h -- Redundant");
} // showHelp()

int main(int argc, char *argv[])
{
    switch (argc)
    {
        case 0:
        showHelp();
        break;
        case 1:
        showHelp();
        break;
        default:
error("Oh, god I've never seen so much blood... did you remember to use a #2 pencil?!");
    } // switch (argc)
} // main()


Of course I use such forced indentation changes sparingly, but they definitely help when it comes to identifying important lines of code. Particularly when I have GUI code mixed in with non-GUI code, I often outdent my refresh and clear functions so that I can easily see exactly where and how I refresh my screen. (I don't use comments because they clutter the code in that instance in my opinion).

As for brace preference, I prefer end... or really any construct that forces the type of the statement to be included (as you can see above).

Another odd bracing practice of mine (more related to scope keywords):

Code: Select all

class MyClass
{// private:
      int myInt;
    public:
      int getMyInt(){return myInt};
};

Re: Braces vs indent vs "end ..." syntax preference

Posted: Sat Nov 29, 2014 12:08 am UTC
by Derek
Braces, but braces should never be optional. That was a mistake of early C-syntax languages (BCPL?). Braces are easier for tools to support correctly. Indentation should be enforced by the style guide and supported by the editor, but there are rare occasions where you need to do something weird.

Re: Braces vs indent vs "end ..." syntax preference

Posted: Thu Dec 25, 2014 11:37 am UTC
by spaceLem
I prefer end tags, then braces. I really dislike indenting without end tags, as it leads to the situation where

Code: Select all

if condition
    do x
    do y
do z

can get mangled leaving

Code: Select all

if condition
    do x
do y
do z

and you can't tell just from the code that do y shouldn't necessarily be executed. An end or endif would make it explicit, and allow for the editor to take care of indentation.

Code: Select all

if condition
    do x
do y # error!!
endif
do z

Re: Braces vs indent vs "end ..." syntax preference

Posted: Sat Jan 03, 2015 3:56 am UTC
by cjmcjmcjmcjm
Program in MUMPS

Code: Select all

i ^LOCAL(0,0)'="BONERS" d 
. w !,"Hello world!"

Re: Braces vs indent vs "end ..." syntax preference

Posted: Thu Jan 08, 2015 10:34 pm UTC
by Frankenstein
I was pretty sure I wouldn't find anyone supporting "end..." or braces. Unfortunately I'm coding in C# atm, but I have fond memories of the days when I used to code in Python. Those were the days. You need a decent IDE/Editor though if you don't want to have problems with space/tabs mixing, and spaces mismatching.

Re: Braces vs indent vs "end ..." syntax preference

Posted: Thu Jan 08, 2015 11:40 pm UTC
by EvanED
I have a new-old complaint about Python's lack of braces: you can't copy and paste many functions and most classes into the REPL, because blank lines will cause the REPL to consider the construct ended.

Re: Braces vs indent vs "end ..." syntax preference

Posted: Fri Jan 09, 2015 12:14 am UTC
by Nyktos
That is the one thing that really does bother me about Python's syntax. You can use exec() with multiline strings as a workaround, though.

Re: Braces vs indent vs "end ..." syntax preference

Posted: Fri Jan 09, 2015 12:17 am UTC
by Thesh
Nyktos wrote:You can use exec() with multiline strings as a workaround, though.


...

No. Just... No.

Re: Braces vs indent vs "end ..." syntax preference

Posted: Fri Jan 09, 2015 12:28 am UTC
by Nyktos
I'm talking about at the REPL, not in your actual code. As in:

>>> exec("""
... # copy-paste here
... """)

Re: Braces vs indent vs "end ..." syntax preference

Posted: Fri Jan 09, 2015 12:30 am UTC
by Thesh
Oh, sorry, I just skimmed EvanED's post.

Re: Braces vs indent vs "end ..." syntax preference

Posted: Sat Jan 10, 2015 11:36 am UTC
by lorb
Nyktos wrote:I'm talking about at the REPL, not in your actual code. As in:

>>> exec("""
... # copy-paste here
... """)


But you have to worry about escaping tripple quotes in the copy-paste. (docstrings)

Re: Braces vs indent vs "end ..." syntax preference

Posted: Sat Jan 10, 2015 7:12 pm UTC
by Nyktos
Python allows embedding one kind of triple quotes inside the other. If you always use triple double quotes for docstrings as PEP 257 recommends, you can use triple single quotes for copypasting.

Re: Braces vs indent vs "end ..." syntax preference

Posted: Tue Jan 13, 2015 10:22 pm UTC
by Derek
The real problem here is that newline is interpretted as "try to execute the the previous line(s)" by most REPLs. This is an obviously ridiculous design, almost every programming languages ever is designed to be written in multiple lines, and newline means insert a new line. "Execute the previous lines" should be a completely separate command. Preferably one that cannot be copy-pasted, like Shift+Enter.

Re: Braces vs indent vs "end ..." syntax preference

Posted: Sun Feb 22, 2015 2:52 am UTC
by Xanthir
After two years of writing Python, and writing a *bunch* of custom syntaxes for Bikeshed, indent is still my favorite way to do things. It's simple and easy, and it makes it really easy to move blocks of code around. I find that really useful in my indent-based microlanguages, like railroad diagrams - twerking a diagram often involves shifting around blocks and reparenting, which is super-easy in the indent syntax and *really* annoying and error-prone in the function-based syntax.

Of course, this is assuming you're using tabs as God intended.

Ultimately, though, anything is okay as long as there's a consistent and enforced formatting style. Indentation gets you that for free; if you're using any other block style, your language better have an autoformatter, like Common Lisp or Go.

Re: Braces vs indent vs "end ..." syntax preference

Posted: Wed Feb 25, 2015 1:30 pm UTC
by ucim
If something reads your lips, it's a tool.
If something reads your mind, it's the enemy.

Braces and end-statements read your lips; they require you to explicitly say what you mean. I favor them.

Indent reads your mind. It gives semantic meaning to formatting. Invisible characters should not be executable.

That said, I sometimes use the indenting method for pseudocode I am jotting down as a reminder of what I want to do. But for real code, that gets executed, I prefer to explicitly rather than implicitly tell the machine what to do. Invisible statements should not exist.

Now, between braces and end-statements, I prefer braces. They are easy to line up, and easy to type. They also have the (slight) advantage that I can clearly code some simple things on one line, that would otherwise be less clear:

if (condition) {do this}
if (another condition) {do that}
if (a third condition && a fourth condition) {do something else}

which is compact, clear, and unambiguous.
Spoiler:
Most code should not be compacted like this, but sometimes it's really useful to be able to do so.
The same thing with words:

if (condition) do this; endif;
if (another condition) do that; endif;
if (a third condition && a fourth condition) do something else; endif;

is visually less clear although equally unambiguous.

With indent (which I'm not sure how to show without an ugly code block), one is forced into:

if (condition)
..do this
if (another condition)
..do that
if (a third condition && a fourth condition)
..do something else

which takes up precious vertical space, and sometimes vertical compactness makes things easier to see.

Jose

Re: Braces vs indent vs "end ..." syntax preference

Posted: Wed Feb 25, 2015 3:42 pm UTC
by EvanED
I've said above that I've come to dislike whitespace-sensitive block structures more than I like it, but:
ucim wrote:If something reads your lips, it's a tool.
If something reads your mind, it's the enemy.

Braces and end-statements read your lips; they require you to explicitly say what you mean. I favor them.

Indent reads your mind. It gives semantic meaning to formatting. Invisible characters should not be executable.

I honestly don't understand this argument. How are they invisible? Do you use an editor that collapses whitespace a la HTML or something?

The only thing about that statement that makes any sense to me is the fact that there's the potential for confusion between tabs vs spaces, because the difference usually are invisible. But (1) I think that's mostly an argument for coding standards that prohibit tabs, and (2) it's totally possible to make a whitespace-sensitive language that makes it a syntax error to have code that admits the possibility of confusion. (And Python 3 does, and Python 2 does if you pass a flag to the interpreter.)

[Braces] also have the (slight) advantage that I can clearly code some simple things on one line, ... with indent (which I'm not sure how to show without an ugly code block), one is forced into:

if (condition)
..do this
if (another condition)
..do that
if (a third condition && a fourth condition)
..do something else

which takes up precious vertical space, and sometimes vertical compactness makes things easier to see.
Or, you know, you could say

Code: Select all

if condition: do this
if another condition: do that
if a third condition and a fourth condition: do something else

at least in Python.

You can even put multiple statements on one line in a conditional:

Code: Select all

>>> def f(x):
...     if x: print 1; print 2
...
>>> f(1)
1
2
>>> f(0)
>>>

Re: Braces vs indent vs "end ..." syntax preference

Posted: Wed Feb 25, 2015 3:44 pm UTC
by Nyktos
ucim wrote:if (condition)
..do this
if (another condition)
..do that
if (a third condition && a fourth condition)
..do something else
Python has absolutely no problem with "if condition: do_a_thing()" on one line.

Re: Braces vs indent vs "end ..." syntax preference

Posted: Wed Feb 25, 2015 9:51 pm UTC
by Derek
I hate one line if statements anyways. My experience is that far too often they need to expand later anyways, and then it's annoying to have to change them to multiline. It's not unusual for them to go back to single line too (maybe you added a debug statement and then removed it, or you changed your mind about a previous addition), and then you feel obliged to go from multiline to single line again.

So just always make all your block statements multine, and always wrap them in braces. It saves you effort in the long run.

Re: Braces vs indent vs "end ..." syntax preference

Posted: Fri Feb 27, 2015 12:24 am UTC
by chridd
EvanED wrote:I have a new-old complaint about Python's lack of braces: you can't copy and paste many functions and most classes into the REPL, because blank lines will cause the REPL to consider the construct ended.

Code: Select all

>>> def foo():
...     print "hi"
...     
...     print "bye"
...
>>> foo()
hi
bye
Works fine for me :wink:
(...highlight the code to see how I did it...)

EvanED wrote:(1) I think that's mostly an argument for coding standards that prohibit tabs
...you mean, an argument for coding standards that prohibit spaces?

Re: Braces vs indent vs "end ..." syntax preference

Posted: Sat Feb 28, 2015 5:21 pm UTC
by ucim
EvanED wrote:
ucim wrote:Indent reads your mind. It gives semantic meaning to formatting. Invisible characters should not be executable.
I honestly don't understand this argument. How are they invisible? Do you use an editor that collapses whitespace a la HTML or something?

The only thing about that statement that makes any sense to me is the fact that there's the potential for confusion between tabs vs spaces, because the difference usually are invisible.
Yes, that's it. And if you copy tabs, sometimes you get spaces. And while you could work around it by going through extra trouble to prohibit tabs, or ambiguity, avoid certain text editors, or whatnot, that's extra trouble that invites more extra trouble.

You replied to my indent example that you could do

Code: Select all

if condition: do this
if another condition: do that
if a third condition and a fourth condition: do something else
but this does not use indents. I suppose it relies on the start of a line to end the if statement, but if you need to reformat or reflow (to view in a narrow window) the visual information is lost.

It's not impossible. Just inferior.

Derek wrote:I hate one line if statements anyways. My experience is that far too often they need to expand later anyways, and then it's annoying to have to change them to multiline.
I know. It's a ch*rp in the mustard. But in the meanwhile more code is visible in the window, which is a good thing. So sometimes I do it. Sometimes I don't. But I like to be able to.

Jose