Curly Brackets?

ID:151508
 
Jul 27 2010, 10:52 pm
For a while now I've seen some developers use curley brackets such as '{}' in their programming for example:
datum
{
    blah
    {
        if(blah)
        {
            ..()
        }
    }
}


Is there a reason behind this? Does it do anything for the effeciency in any way? or is it just a hobby of their's.
Jul 27 2010, 11:05 pm
It is all just the developers preference. Most who would do that have knowledge in languages such as C++ when that is how the code is structured.
Jul 29 2010, 6:15 am
In response to National Guardsmen
yeah, it keeps the code less messy, but it costs too much time to digit { and }
Jul 29 2010, 9:49 am
Byond is based on C++. Because of this, there are many C++ style things you can do in your code.
var myGlobalVar = "hi";

proc/myFunction()
{
    var myLocalVar = 5;
    var i;
    
    world << myGlobalVar;

    for(i = 0; i < myLocalVar; i += 1)
    {
        world << i;
    }
}

And there are some other things too.

Since you can do "var myVar" separating it with a space instead of a slash, like in C++, I was expecting to be able to do "proc myProc()" as well, but that does not compile. Oh well.

With any of this, your mileage may vary. For example, doing "var myVar" does not work anywhere you can normally use "var/myVar"
Jul 30 2010, 8:17 pm
Is there a reason behind this? Does it do anything for the effeciency in any way? or is it just a hobby of their's.

Like already stated it tends to just be a preference or habit thing. With indentation stuff now, they do absolutely nothing unless you're packing a bunch of statements on one line. But they used to be required way back when!
Jul 31 2010, 6:20 am
In response to Karffebon
I personally find it to look messier to me, but that's only because I'm not used to using them. Someone who is used to them probably finds it a very comforting thing to do and feels it looks a lot better that way.
Jul 31 2010, 6:24 am
In response to Fugsnarf
Always using brackets and as such is actually worse because of objective reasons. Of course, that's not to say that someone who's been using them for ages won't still prefer them in favor of indentation-only, even though the latter is superior.
Jul 31 2010, 8:42 am
In response to Kaioken
How do you figure this?
Jul 31 2010, 9:24 am
In response to Stephen001
Brackets are redundant because good programming style already dictates that you use consistent indentation to indicate blocks. One could say that it's an advantage of languages such as BYOND or Python that this is enforced, as many programmers don't learn how to do it when blocking is done entirely using brackets.
Jul 31 2010, 9:53 am
In response to Stephen001
I tried to leave the reader to work his own logic and common sense, but since you've asked...

Consistently giving code block delimiters to the compiler as braces and semicolons instead of whitespace as code block delimiters creates the following disadvantages (not a complete list):
  • They're one more thing to worry about, making the programming process more complex. In addition to maintaining indentation for proper readability, the programmer also has to add extraneous delimiter marks and synchronize them with the indentation he uses to read the code, so code blocks are harder to maintain.
  • The compiler and the programmer read the source code in a different manner, instead of exactly the same way. The compiler scans for the braces while the programming instinctively checks out the indentation. This of course makes programming even more complex and leads to minor mistakes every once in a while, as it's harder to instinctively follow your code flow; you have to watch out for the braces and if the indentation actually matches them.
  • Because indentation is made optional, the programmer can opt to skip maintaining it because of laziness and the illusion that the code is readable enough as is (because he can easily follow it right now, after just writing it), ultimately deteriorating the overall readability of his source code.
  • Naturally, having extra symbols all over your source code bloats it, making it less clean and readable.
  • Distractingly, there are many different styles to use braces in, making choosing how to format your code blocks more complicated and making it more difficult or annoying to read code written by others because they use a different style than you. Naturally, this can also spawn silly discussions and debates.


Garthor also summed up nicely one of the points.
Jul 31 2010, 10:47 am
I only use them for trimming down code lines:
if(something) {var++;world<<var}
Without the brackets it throws world<<var out of the if()
Jul 31 2010, 11:49 am
In response to Falacy
Falacy wrote:
if(something) {var++;world<<var}

Or just
if(something)
    world << ++variable


In any case, I think using braces like that isn't a valid use of them. It's just an attempt by newbies to compactify code that shouldn't be compacted. It ultimately looks extremely ugly, and has no real benefit.
Jul 31 2010, 11:57 am
In response to Kaioken
I thought you said objective, my bad.
Jul 31 2010, 5:02 pm
I come from a managed code background (C#) and find bracketed code far easier to read and maintain. I suffer no delays or hardships by using them. The compiler strips them all out so your code is not bloated at runtime which is when it really matters.

Source code should be absolutely human readable. Its the entire reason we have compilers. They convert something which is human readable into something "computer" readable.

Granted, there are exceptions and they are typically in the extreme realm of micro size and performance. For the average byond developer, there is no reason to compress and compact until your code is nearly cryptic.

In the end, it is simply preference. I wish BYOND would auto-magically add and remove brackets via an option. This way, everyone could toggle as needed for demos and examples.

ts

Aug 4 2010, 12:10 pm
In response to Tsfreaks
Tsfreaks wrote:
The compiler strips them all out so your code is not bloated at runtime which is when it really matters.

Just a technical FYI in case anyone cares (which you might already know).

Whitespace, braces, comments and other extra stuff don't actually get "taken out" of the resulting machine code or byte code. When the code gets parsed, these things just don't have any opcodes that they translate into, and, in the case of braces (and in some languages, such as Byond, whitespace), these things direct the parsing of the text.

I have heard some people say that they think removing whitespace will make their program run faster (I'm not saying you're this silly, Tsfreaks, just giving an example of what I've seen others do). Think about that for a minute; how could it make the program run faster? The CPU gets fed a bunch of instructions, such as "add this register to that memory address" or "swap these two values" or "jump to that memory address and continue executing code from there" There is an instruction that does not do anything; the no-op operation just gets ignored by the CPU so it doesn't do anything for that instruction and continues on to the next instruction, but do you think your empty lines and extra spaces in your code get compiled into no-ops? That would mean that Dan and Tom would originally have had to decide "Hmm, I think we're going to make our compiler translate every character of whitespace into a no-op." If they did do that, then I'll leave it up to you guys to stone them for it. Now, even if they did do that, each no-op might take between a microsecond to a fraction of a nanosecond for the CPU to "process." That's not really a slowdown at all, so even if that were the case that it translates them into no-ops, it doesn't really matter unless you're doing the following:
var/accumulator
for(var/a = 1 to 100)
   for(var/b = 1 to 100)
        for(var/c = 1 to 100)
            accumulator = b+c

            accumulator -= a

But EVEN THEN the addition/subtraction is going to take longer to process (even though an addition and then a subtraction is ridiculously fast) than the no-op, so the no-op STILL doesn't have a significant impact on your code, even in this, the most ridiculous of examples.

In short: having "whitespace" in your byte-code would have insignificant impact even if it somehow were there, but regardless of that, it's not there so there's nothing to worry about!

I hope all that gives you something to think about when you're deciding what to optimize in your code. As some people on the Oracle forum say, "Premature optimization is the root of your bugs."
Aug 4 2010, 12:51 pm
In response to Loduwijk
Yes I'm going to "nit-pick".

There is a lot between compiled DM code and machine code. DM compiles to an intermediate form which gets interpreted by Dream Seeker. I don't think it's a JIT compiling type of deal where DS compiles DM code to machine code on the fly, it's most likely an interpreter written in C++.

The reason whitespace doesn't matter is because the compiler treats 1 + 2 the same as 1 &nbsp; &nbsp; + 2. It has nothing to do with no-ops, it's just how the parser works. When it's parsing arithmetic, whitespace doesn't matter. When you compile in DM and generate the intermediate form (the .dmb) it can ignore whitespace when it doesn't matter.


As Falacy mentioned in [link], using curly braces lets you things that you couldn't do without them. Sometimes it's cleaner to not use indentation to denote blocks of code. Having the option to do this is better than not having that option.


Curly braces are also a visual marker of the end of a block. It's easy to see where a block of code starts because it follows and if or for. Using indentation alone doesn't show where the code blocks end, for example:

proc
    something
        for(var/mob/m in world)
            for(var/x = 1 to world.maxx)
                for(var/y = 1 to world.maxy)
                    // do something
                    
                    
                    
                    // do something else
            
            
            
            
            // this line of code is dangling here, what block is it in?

// compared to:

proc
    something
        for(var/mob/m in world)
        {
            for(var/x = 1 to world.maxx)
            {
                for(var/y = 1 to world.maxy)
                {
                    // do something
                    
                    
                    
                    // do something else
                }
            }
            
            
            // this line is inside the first loop only because only one closing curly brace follows it
        }


If you replace the comments with a lot of code and you add a few more blocks, it's easy to lose track of what block some code is in.
Aug 4 2010, 5:06 pm
In response to Forum_account
Forum_account wrote:
If you replace the comments with a lot of code and you add a few more blocks, it's easy to lose track of what block some code is in.

Options > Show Tabs. It effectively creates a vertical visual line that you can use to trace what lines up with what. Although, I suppose it requires that you scroll down until you see an instruction on a lower tab level to know that a code block has ended.
Aug 12 2010, 4:14 am
In response to Forum_account
Forum_account wrote:
Yes I'm going to "nit-pick".

It's not really nit-picking since you're not disagreeing with anything I said.

Yes, DM compiles to byte code that is interpretted by Dream Seeker, and all of the above was written in C++.

I wasn't saying whitespace compiles into a no-op, in fact I said that it does not. I said that the people who think whitespace affects your game somehow must think that the "line that does nothing" must compile into "something that does nothing" and take up time doing nothing; I don't understand how else they think whitespace could affect things. Even if that were the case, I was getting at, it would not matter and would not impact anything, but that it's not the case.

Sometimes it's cleaner to not use indentation to denote blocks of code. Having the option to do this is better than not having that option.

I agree, as long as it is not overused.

Sometimes I like packing something onto 1 line if it's insignificant and I won't ever have to care about it again and I don't want it to get in the way when I'm scanning through my code. I don't do this in Byond, but I do it a lot in C++. Stuff like extra constructors/destructors that aren't as important and can be one-liners. I think this really helps so you can ignore stuff that doesn't matter as much.
Aug 12 2010, 6:12 am
In response to Loduwijk
Loduwijk wrote:
I wasn't saying whitespace compiles into a no-op, in fact I said that it does not. I said that the people who think whitespace affects your game somehow must think that the "line that does nothing" must compile into "something that does nothing" and take up time doing nothing

I guess I didn't elaborate enough.

I don't think the problem is that people understand compilers and CPU instruction sets but believe that whitespace would be translated to no-ops. I think the problem is that people don't understand how compilers and interpreters work.

For some people the misunderstanding is in how BYOND processes things. It does not read your code, parse each line, and process it as the game is running. DM code is compiled to a different form before running it. People who don't understand this are correct in thinking that whitespace would slow things down because each line would take more time to process, but this isn't how things are done. It's intuitive, but incorrect.

The misunderstanding might also occur in how the compiler works. To the programmer BYOND appears to interpret one line of DM code at a time, as if each line of code translates to one command (and all commands take the same time to process). By packing more into one line you accomplish more with each command. By omitting whitespace (avoiding line breaks) you can put more commands into one line of DM code. The problem is that when compiling to a reduced instruction set, one line of higher level code can become multiple commands. The lower level details aren't always obvious at a higher level, so this is a reasonable mistake too.

If you understand how CPUs and compilers work you shouldn't make either of these misunderstandings.

Both of these ideas contribute to the idea that concise code is fast. To some that seems intuitive and helps to further the idea that whitespace is the enemy. It also introduces new ways of butchering code that wouldn't help efficiency by any amount of flawed logic. Understanding how compilers and interpreters work would help, but you don't need to understand your CPU's instruction set to understand this.