Retrospective changes to the lessons: 1TBS

Once again, I’ve been through the previous posts and made a number of changes. Most of them are cosmetic in nature, but one looks cosmetic but isn’t.

A good way to start a violent argument between developers is to start talking about indentation styles. When you have an “if” statement or a function definition, do you put the brace (“curly bracket”) that follows it on a new line of its own, or at the end of the line with the “if” that it belongs to?

In most languages, this is a purely aesthetic matter (which is probably why people argue about it so much). I personally prefer the Allman style because I think it looks nicer, and so that’s what I’ve used until now.

However, it turns out that in JavaScript it’s not just a matter of taste. Jos Hirth pointed out in the comments that because semicolons are optional, putting braces on a line of their own can lead to code that looks like it does one thing but actually does another:

If something doesn’t make sense, the parser jumps back, adds a semicolon, and tries again.

So, if you write something like:

return
{
    foo: ‘bar’
};

It will return undefined!

Not putting the opening brace in a new line is the only indent style you can *always* use.

[JavaScript: The Good Parts, Appendix A: Awful Parts, Semicolon Insertion]

That’s exactly right, and a great point. Presumably this wasn’t a deliberate move on the part of the JavaScript language designers, but it does mean that the style (slightly absurdly) known as “The One True Brace” is the only one you can rely on in JavaScript.

The last thing I want to do is get people into bad JavaScript habits… so, it was a bit dull, but I’ve been through the previous lessons and switched them all over to 1TBS. Future lessons will use it too.

Phew!

That’s not the only retrospective change in the pipeline; on the list of pending suggestions from the comments, I have:

  • Get rid of the timer for repaints in cases where there’s no animation, so as not to constantly repaint things that aren’t changing.
  • Use JavaScript’s prototype feature for classes so that we don’t create a separate set of functions for every object.
  • Switch to a 3×3 normal matrix for efficiency.
  • Improve the code that reads from text fields so that it’s not executed on every repaint
  • Put JavaScript tags for strict lint-checking

In addition, I’m hoping I can get rid of the stuff at the top of every file that’s there to deal with compatibility issues in old browsers — more about that in the next post.

Have I missed anything? Is there anything about the code here that bugs you? Let me know in the comments.

You can leave a response, or trackback from your own site.

4 Responses to “Retrospective changes to the lessons: 1TBS”

  1. To anyone who cares, although I haven’t made any public releases for a while. WebGLU (sf.net/projects/webglu) is still around and growing, it takes care of many of the more repetitive parts of working with WebGL. It’d be WebGL for the lazy if GLGE hadn’t taken that slogan XD. Though of course you should see what tools are available and pick the best for you in any case.

  2. murphy says:

    Thanks for the cleanup! I prefer 1TBS. Less LoC makes more code visible on my 13″ screen.

  3. steve says:

    Thanks for the updates! It’s the maintenance of your code base that makes your lessons so valuable, rather than decaying into something that once worked.

  4. giles says:

    @Benjamin — let me know if there are any big changes that should be in one of the roundups.

    @murphy, @steve — no problem, glad that the endless fiddling isn’t irritating you ;-)

Leave a Reply

Subscribe to RSS Feed Follow Learning WebGL on Twitter