Hacker News Reader

I started a project out using jade in nodejs, after a while I had a page with enough elements/nesting going on that I was having a hard time keeping track of what was grouped where. Particularly when taking some work a designer did, making it jade compliant, then pasting in.

Aside from a short "if" statement, I now no longer think it's sexy to abandon ending notation whether it be braces, elements, etc.

I'd suggest you not leave if statements un-braced. I remember a study where they found the most common bug in most experienced open source developers was leaving out the braced initially, going back to make a change, and having that change introduce a bug.

Basically they had

   if (x)
      then()

and went back and did

   if (x)
      new_call()
      then()

and caused an error that happened silently.

This is something you definitely want to avoid and I personally don't trust myself, after a no-sleep code fixing bender, to remember to add {} around something if I'm editing an if. I'd probably forget.

Again, I'd say shorter does not mean better.

One way round this is to put single statement ifs on a single line:

    if (x) then();

If you add another statement to the if, its obvious from the indent that you need to use braces.

Yup, I always do this when writing JavaScript or other languages that allow prefix single statements with or without braces. Otherwise I use braces if the statement is too long to fit in the editor w/o forcing you to scroll. Perl only allows postfixed single statements w/o braces, so you're safe:

    say "yes" if $condition;
    if ($condition) {
        say "yes";
        $affirmative++;
    }

7: warning: this 'if' clause does not guard... [-Wmisleading-indentation]

if (x)

^~

9 : note: ...this statement, but the latter is misleadingly indented as if it is guarded by the 'if'

then();

^~~~

Relying on compiler-specific features.... where did I hear that before?

Oh yea, undefined behavior. Do you like using undefined behavior?

That's just a warning. It has no effect on the generated code.

It is perfectly acceptable, and in fact considered proper engineering practice, to compile with multiple compilers to take advantage of their warning and static analysis capabilities.

I don't see how having closing braces makes it easier to see what's grouped, though.

If you have a page with enough elements and nesting going on that indentation doesn't make its structure clear, I find it hard to believe that you'll see </div></div></div> and think "oh yes, I just closed <div class='wombat'>".

A good editor may highlight the region that a </div> covers, and/or show the opening element and/or the "path" to the current element in the status bar.

But, a good editor that understands indented syntax could do the same. It is a fault in code editors that they don't often have good features for navigating around source which uses indenting. This isn't a problem with the syntax.

FWIW, I use SLIM - which is a Jadelike language for Ruby - and I hate having to deal with raw HTML. I find it incredibly hard to navigate, primarily because of the lack of indentation. All too often you think a particular block is contained in some element but it turns out it just looks that way because somebody decided to use indentation whitespace decoratively.

> I see no issue with splitting up a problem into multiple parts that, if sufficiently different, could be hidden from each other.

I'd go so far as to say breaking a problem up into black boxes that solve smaller parts of the problem is one of the most basic skills in programming.

> Just from a teaching perspective. I help tutor for CS100 at my university and a large part of the errors I have to deal with are whitespace errors. People don't understand where a block starts and ends.

On the flip side, when I was in school and a peer asked me to look over their code, it was usually an unindented mess and they still very much had no idea "where a block starts and ends" despite the braces.

When Python was introduced, I was hopeful that a technical demand that indentation be done properly might actually help, pedagogically. On reflection, imposing this at linting with a brace-based would probably be better still, as the error messages could be substantially better targeted.