Curly Brackets Go Where?

[Xanthir]

Good luck with machine-generated code.

Um, what? I have no idea what that is supposed to mean as a response to my comment

It's easy to machine-generate brace-delimited blocks. Machine-generating whitespace-delimited blocks is more of a challenge: it turns your code generator (which is one project) into a code generator with a pretty-printer attached (which is two projects).

I thought that's what you meant, but that still has nothing to do with my statement. I said that whitespace is sufficient for human comprehension of the code; you countered with "but machines have a hard time generating that code". And?

For one, the other brace styles aren't *un*readable, just *less* readable to me. For two, you're actually looking at machine-generated code? The whole point of machine generation is that you don't look at it. If you're talking about machine-generated *scaffolding*, then you're working in the wrong language. Learn to use a functional language and stop making our eyes bleed.

As well, pretty-printers can be produced once and then reused everywhere, so there's no need to double the work in every project for that. So you have a code generator, which runs the generated code through an external pretty-print library once, at the end.

Don't whine to me about wasting whitespace, we aren't using teletypes anymore. Whitespace is cheap.

Um, no. Whitespace is *expensive* in terms of comprehension. The more you can comprehensibly fit into your eye, the better. Stretching a function out over a whole page when it can be compressed into less than half that space without losing comprehensibility is a crime.

Yes, but that's a question-begging way of putting it. "Without losing comprehensibility" is exactly the question here. And the better question is, "when and where does whitespace enhance comprehensibility"?

For instance:

Code: Select all

function(a, b, c){foo(a); bar(b); baz(c);}foo(x){fred(x+10)}fred(a){function(a, a, a);}

has no whitespace, and is thus unreadable, even though it fits within 80 columns or so.

Indeed, that *is* unreadable. Which is why I would never encourage it (thanks for the strawman, though!). My comments that you responded to explicitly recommended whitespace, in order to delimit blocks. If I was writing that code, it would be:

Code: Select all

function( a, b, c ) {
   foo(a);
   bar(b);
   baz(c);}
foo( x ) {
   fred(x+10)}
fred( a ) {
   function(a, a, a);}


Now look over BOTH blocks of code and tell me: where is the missing semicolon more apparent? (Yes, even if your compiler helpfully informs you what column your missing semicolon is on, and not just what line.)

Now that we've disposed of the false dilemna you attempted to employ to support your point, we can see that the error is equally obvious in both our code. Mine'll say "missing semicolon on line 6", and when you look at line 6, there it is!

Consider:

Bagels
Dishwasher soap
Bratwurst
K-Y Jelly

vs.

Bagels, dishwasher soap, bratwurst, and K-Y jelly.

In code:

Code: Select all

if (
    gotBagels() &&
    gotDishwasherSoap() &&
    gotBratwurst() &&
    gotKYJelly() &&
    )
  leaveStore();


vs.

Code: Select all

if (gotBagels() && gotDishwasherSoap() && gotBratwurst() && gotKYJelly())
  leaveStore();


At this point neither are good. The correct way to do this is:

Code: Select all

if( gotAllOnList( list, cart ) ) {
  leaveStore();
}


If you have to worry about how to format a conditional, you're doing it wrong. Refactor. There's no need to have formatting wars over conditionals, because by the time it becomes necessary you've already lost.

[TheOrangeMan]

on a new line and indented, just as nature intended.

[0xBADFEED]

on a new line and indented, just as nature intended.

Do you mean like GNU style :

Code: Select all

if(x)
  { 
    do_something();
  }


or Whitesmiths style ?

Code: Select all

if(x)
    {
    do_something();
    }


Actually, I guess it doesn't really matter. They're both about equally horrendous to look at, with Whitesmiths being slightly less bad.

[enk]

This is kind of a necro. But there's a whole new aspect to this topic:

Code: Select all

MAIN()
  IO.write("Hello, World!\n")
}


http://www.zimbu.org/

[ash.gti]

Oh god you can't even tell where it starts...

[zombiefeynman]

Heck, I'd use GNU Style before I'd use that...thing.

[lulzfish]

edit: I think the forum ate my indentation.
Pretend that this post is indented properly!

I like same-line.
The time I tried to use Python, I remember that the indentation thing threw me off a lot.

It's a good idea, but I want code to look like this:

class blah
stuff
stuff
end class

The C / C++ / Java style is a nice compromise:

class blah {
stuff
stuff
}

But Python leaves the end open, and I can't tell at a glance where the block ends:

class blah
stuff
stuff

?? class ends? maybe, maybe not.. Visually unsettling.
This bothers me more than the positioning of brackets, by far.

[enk]

Oh god I can't even tell where it starts...

Fixed that for you.

[ash.gti]

Okay, granted I don't know all the grammar of that language, it does seem somewhat... illogical that they have a random character to end a block segment that is traditionally paired. Most people that see a { will look for the closing } to find the end, same goes in the other direction, if you noticed a ) wouldn't you try to see where that ended? It would almost make more sense if the language took a more functional approach and said

Code: Select all

MAIN(
  ...block content...
)


because at least then we'd have a logically matching pair of characters that encompasses a block. The closing '}' character has no logical purpose because the language isn't giving us a reason to expect a character as a block closing argument when it already used a word to start the block with no significant indication a block is being started.

[enk]

Okay, granted I don't know all the grammar of that language, it does seem somewhat... illogical that they have a random character to end a block segment that is traditionally paired. Most people that see a { will look for the closing } to find the end

Well, I just posted it to spark interest to follow the link.

The } character is used to end a block. There is no {, we know where the block starts. This avoids useless discussions about where to put the {.

An unorthodox move, sure. But still noteworthy.

[Philwelch]

There are certain things that just break the human brain sometimes. Using an end bracket, end paranthesis, or the like without a matching opening character is one of them (with the exception of emoticons). People like symmetry, which is why even weird attempts at symmetry (i.e. "fi" to end an if block in shell scripting) are better than that.

[Berengal]

Also: Tags vs parens. I should really finish my sexpr <-> xml converter and restore some of the sanity I've lost...

[Gaydar2000SE]

Depends , if my code should be readable to others:

Code: Select all

//this function shall do the thing that's immediately visible from it but because I think you are stupid, I'm going to put it here any way
function prime_counter($max_int) {
   
   $i = 1;
   
   while ($i <= $max_int) {
   
      $j = 2;
      
      while($j < $i) {
      //this part is dead obvious, if the remainter is zero it is divisible, zero evaluates to false.
      if($i % $j) {
      $string .= "divisible by $j; ";
      
      }
      $j++;
      }
      
      //this part is also obvious, but I'm going to explain it as I expect my readers to be stupid
      if (!$string) {
      
      $string = "$i is prime; ";
      $list[$i]['is_prime'] = true;
      $number_of_primes++;
      } else {
      
      $list[$i]['is_prime'] = false;
      }
      
      $list[$i]['details'] = $string;
   $i++;
   }
   
   
   $list['number_of_primes'] = $number_of_primes++;
   
   return $list;
   
}




If it's for myself only:

Code: Select all

function nrfx($kjlr) { $i = 1; while ($i <= $kjlr) { $j = 2;

while($j < $i) {
if($i % $j) { $strLOLAIDSLOL .= "divisible by $j; ";}$j++;}
if (!strLOLAIDSLOL) {$string = "$i is prime; ";$list[$i]['is_prime'] = true;$number_of_primes++;} else {

$list[$i]['is_prime'] = false;} $list[$i]['details'] = $string $i++; }$list['number_of_primes'] = $number_of_primes++;return $list;}




[Reg Berkeley]

I prefer new line, disregarding the effect of whitespace.

[Gaydar2000SE]

About that discussion above, people, and a lot tend to forget that different people have different tastes and find different things readable. I'm personally on the far end and find verdana, 5pt, #050505 on #000000 quite readable in normal daylight, though not at night. Also, larger texts decreases readability for me, as does a higher contrast which tires my eyes. #FAFAFA on #FFFFFF is also good but still I'd rather have it inverted. The reason larger text decreases readability for me is because I read multiple lines at the same time and just add them together at the end. It's rare but it makes sure I never read any adds on posters because the lines are too big and too far apart, and I can't catch multiple lines in my focal point, thus making it extremely tiresome for me to read a story if I can only read one line at a time. Just to show the extreme possibilities, I know of at least one other person that expressed similar discontent so it should not be that rare.

Same of course with whitespaces in programming blocks, people often forget quite often that different people have different needs. A lot of parenting magazines are profoundly lacking in realizing (or commercially ignoring) that different children have different needs and at max your advice will only be good for 60 per cent of the children, and may very compromise the rest.

Okay, granted I don't know all the grammar of that language, it does seem somewhat... illogical that they have a random character to end a block segment that is traditionally paired. Most people that see a { will look for the closing } to find the end, same goes in the other direction, if you noticed a ) wouldn't you try to see where that ended? It would almost make more sense if the language took a more functional approach and said

Code: Select all

MAIN(
  ...block content...
)


because at least then we'd have a logically matching pair of characters that encompasses a block. The closing '}' character has no logical purpose because the language isn't giving us a reason to expect a character as a block closing argument when it already used a word to start the block with no significant indication a block is being started.

The key here is that it makes compiling or interpreting that much faster. Programming languages are also written with that in mind. In theory you can even do

Code: Select all

function_name argument1 argument2 argument 3;
block of code;

function_name ...




But then the parser first has to check the line, then conclude that it doesn't match a normal expression by all comparisons, and then conclude that it is a function. Whereas a string sans a space followed by '(' can immediately be concluded as a function, thus sparing time.

[enk]

[...] the parser first has to check the line, then conclude that it doesn't match a normal expression by all comparisons, and then conclude that it is a function. Whereas a string sans a space followed by '(' can immediately be concluded as a function, thus sparing time.

[citation needed]

[Rysto]

I can't give a cite, but I can tell you that such a language would not be LR(1), which means that parsing it would quite inefficient(and there are few parsing tools out there that can handle non-LR(1) languages). I'm not even sure if a GLR parser would suffice.

To prove that it's not LR(1), consider the example already given:

Code: Select all

function_name1 argument1 argument2 argument 3;
block of code;

function_name2 ;

When the parser has the token function_name2 in its lookahead buffer, it has to decide whether the function definition has ended(because a new function definition is starting) or whether to continue parsing statements from function_name1. The token function_name2 doesn't give enough information to make that decision. If the token following function_name2 is a := then it must be an assignment statement; if it's a semi-colon it must be a function definition. But this is a LR(1) parser, so it's only allowed to look at one token of lookahead, so it doesn't have enough information to make the decision.

[enk]

I don't completely get that example, but the parser doesn't need to know what it's looking at from one token to have a lookahead of one, does it?

I mean..

Code: Select all

int foo;
int bar();


and C is LR(1) iirc.

[Rysto]

I don't completely get that example, but the parser doesn't need to know what it's looking at from one token to have a lookahead of one, does it?

I mean..

Code: Select all

int foo;
int bar();


and C is LR(1) iirc.

C isn't even an unambiguous language, let alone LR(1). In your particular example it doesn't matter because the parse can keep shifting tokens before deciding to reduce them into a declaration. In my example, if function_name2 begins a new function definition then the parser must reduce the previous statements into a function definition while function_name2 is still at the beginning of the lookahead buffer. Once the token is shifted onto the stack it must be a part of the next reduction, so shifting the token function_name2 means that the parser cannot reduce the statements preceding it into a function declaration.

[enk]

C isn't even an unambiguous language, let alone LR(1)

Aren't you thinking of C++?

[Rysto]

C isn't even an unambiguous language, let alone LR(1)

Aren't you thinking of C++?

No, although C++ is even worse, with Stroustrup taking the terrible syntax of C and hacking it to bits.

Consider the following:
f * y;

f (a);

The interpretation of either depends on whether f has been previously declared as a typedef name.

[enk]

C isn't even an unambiguous language, let alone LR(1)

Aren't you thinking of C++?

No, although C++ is even worse, with Stroustrup taking the terrible syntax of C and hacking it to bits.

Consider the following:
f * y;

f (a);

The interpretation of either depends on whether f has been previously declared as a typedef name.

Yeah, ok.

I misunderstood the example gaydar posted as well. Go me. And go offtopic

[Random832]

I use a style of coding that does not require curly brackets:

Code: Select all

if (a != 1) goto lbl;
    //stuff
lbl:

[666alphaomega666]

apparently, i tied it up. awesome.

yea, new line definitely. i just think it looks much more... even.

Code: Select all

public static void main(String[] args) {
//god i hate this method already
}

public int symmetry()
{
//wonderful.
}


[stephentyrone]

I use a style of coding that does not require curly brackets:

Code: Select all

if (a != 1) goto lbl;
    //stuff
lbl:

Win.

[Qoppa]

After spending the past two months coding with Java for a class, I'm now much more tolerable of putting curly brackets on the same line. Nevertheless, I will continue to put them on a new line when coding in C or C++.

[hotaru]

apparently, i tied it up. awesome.

yea, new line definitely. i just think it looks much more... even.

Code: Select all

public static void main(String[] args) {
//god i hate this method already
}

public int symmetry()
{
//wonderful.
}


how is that more even than this?

Code: Select all

int some_function()
{ /* some code
     goes here */
  return 0; }


[666alphaomega666]

theyre vertically aligned, and vertically aligned things are sexy.

[hotaru]

theyre vertically aligned, and vertically aligned things are sexy.

vertically aligned curly brackets look like this:

Code: Select all

  {
   }

not like this:

Code: Select all

{
}

[Philwelch]

No. *horizontally* aligned curly brackets look like

Code: Select all

{}

*vertically* aligned curly brackets look like

Code: Select all

{
}


and *diagonally* aligned curly brackets look like

Code: Select all

 {
  }


[hotaru]

*vertically* aligned curly brackets look like

Code: Select all

{
}


and i suppose you think this is the correct way to align numbers:

Code: Select all

  1.234
  12.34
  123.4

rather than this:

Code: Select all

    1.234
   12.34
  123.4

[Area Man]

*vertically* aligned curly brackets look like

Code: Select all

{
}


and i suppose you think this is the correct way to align numbers:

Code: Select all

  1.234
  12.34
  123.4

rather than this:

Code: Select all

    1.234
   12.34
  123.4

That's a completely faulty comparison: brackets and words are not place-value dependent; they have neither magnitude columns nor a common centre, you only indent them.
You can write either flush-right or left, but only numbers have to be 0-padded on a (respective) side for proper decimal alignment.

Code: Select all

BEGIN
     END;

is not aligned, it's staggered.
Additionally, such spacing is an *error* in an indentation-delimited language.

[Random832]

Additionally, such spacing is an *error* in an indentation-delimited language.

Um, don't indentation-delimited languages kind of not have END keywords or brackets?

[Area Man]

I seem to recall vb enforcing indentation while requiring such verbosity in addition.
Nevertheless:

Code: Select all

    fooz.member = 1;
  animal.cow;
     obj.func();
 roosters.create();


is a fucked up way to write code.

[ash.gti]

I seem to recall vb enforcing indentation while requiring such verbosity in addition.
Nevertheless:

Code: Select all

    fooz.member = 1;
  animal.cow;
     obj.func();
roosters.create();


is a fucked up way to write code.

If, for whatever reason, you do want to line up the dots in a lot of languages you can add whitespace between the object and the .method_name, like:

Code: Select all

fooz    .member = 1;
animal  .cow;
obj     .func();
roosters.create();


but i honestly wouldn't do that either.

[Berengal]

Anyone done this before? *Checks thread*. Not in this thread at least.

Code: Select all

>>> from __future__ import braces
SyntaxError: not a chance (<pyshell#58>, line 1)

Brackets are dumb.

[Philwelch]

I seem to recall vb enforcing indentation while requiring such verbosity in addition.
Nevertheless:

Code: Select all

    fooz.member = 1;
  animal.cow;
     obj.func();
roosters.create();


is a fucked up way to write code.

If, for whatever reason, you do want to line up the dots in a lot of languages you can add whitespace between the object and the .method_name, like:

Code: Select all

fooz    .member = 1;
animal  .cow;
obj     .func();
roosters.create();


but i honestly wouldn't do that either.

Dots are a dumb thing to line up, but other things work out alright.

Code: Select all

       FOO       = 120
       FOOBAR    =  40
       QUASIMODO =   6
 
       if ( foo        ==  FOO       ||
            bar        ==  QUASIMODO ||
            salamander ==  FISHSTICKS
          )


[hotaru]

That's a completely faulty comparison: brackets and words are not place-value dependent; they have neither magnitude columns nor a common centre, you only indent them.

brackets do have a common center, to the right of the opening bracket and to the left of the closing bracket.
also, do you really say /ˈsɛntreɪ/, or just spell it that way?

[phlip]

Along with spelling it differently, it seems we have a different definition of the word "centre"... see, we don't usually define it to mean "a point on the edge of something".

[hotaru]

Along with spelling it differently, it seems we have a different definition of the word "centre"... see, we don't usually define it to mean "a point on the edge of something".

so what would you call the point in the middle of a set of brackets?