alternatives to making blocks like { } or other ??

[Michael Chermside]

I (Michael Chermside) wrote:
> a brace and either way it throws the logic off. I created a
> bug in one of
> my programs recently just by adding logging. It looked like this:
>
>     if (some_complicated_condition)
>         log_message("Error has occurred: taking corrective action");
>         take_corrective_action();

Tim Williams replies:
> But here if there were braces, the logic would be right. Indentation
> wouldn't matter.
>      if (some_complicated_condition) {
>          log_message("Error has occurred: taking corrective action");
>          take_corrective_action();
>      }

If you were writing in Python the logic would be right also. I suppose
you have one valid point... a language which *required* braces
everywhere wouldn't be susceptable to this kind of error. But that
rules out C, C++, Java, even things like Pascal.

My second example was:
> When I read through the code it LOOKED like it worked, but of course
> the corrective action was taken even when it wasn't needed. I've also
> seen more complex examples like this:
>
>     if (condition_1) {
>         code_1;
>     } else if (condition_2)
>         if (condition_2_a) {
>             code_2_a;
>         }
>         // nothing to do for 2b
>     else {
>         code_3;
>     }
>

To which Tim replies:
> Looks like an argument for braces to me.

Not at all. If written in Python, we have this:

    if condition_1:
        code_1
    elif condition_2:
        if condition_2_a:
            code_2_a
        # nothing to do for 2b
    else
        code_3

which is correct (not to mention being shorter).

I then gave this example:
> But the ones that I hate the MOST are the ones that my unit
> tests can't
> catch. A typical example looks like this:
>
>     if (condition) {
>         code;
>         goes;
>     here;
>     } else {
>         more;
>         code;
>     }
>
> Notice how that one line ("here;") is indented wrong? Obviously, that
> doesn't meet our coding standards, yet there's no way for the compiler
> to catch it, because the compiler looks only at the braces and ignores
> the indentation!

And Tim replies:
> Here again indentation doesn't matter. A smart editor could do a
> "pretty-print" for you using the braces. I agree that *visually*
> indentation w/o the braces are nice, but as a check for having code
> in the right logical block, it's just too easy have a stray extra or
> missing space (for me anyway) that would throw everything off. Isn't
> just one space needed in Python to signify a different block?

You see, this is exactly my point. Indentation DOES matter... even
in C. It just doesn't matter TO THE COMPILER. But it still matters
to those who have to read it and edit it. In Python, even a *dumb*
editor will "pretty-print" for you.

Your last question suggests a possible explanation. Perhaps you
think that Python code will execute incorrectly if a single extra
space is typed someplace. That simply isn't true. Python relies on
two different cues to indicate a block... one is the indentation,
and the other is the presence of a colon (and a statement like
"if" or "def" which can introduce a block) on the previous line.
If you accidently type an extra space, creating something like
this:

    if condition:
        do()
         some()
        stuff()

...then the compiler will find a syntax error (at compile-time, not
runtime) and complain about inconsistant indentation. This lets you
fix indentation mistakes. If you WANT to write code like this:


    if (condition) {
        do();
         some();
        stuff();
    }

then you're out of luck (and crazy to boot!). But if mis-indented
code is just an accident of messed up typing, then Python helps you
to catch the mistake. I could similarily complain about C breaking
every time I type an accidental "{" in the middle of my code, but
the argument would carry no weight because the compiler would
catch such a mistake at the next compile. And that's just what the
Python compiler will do for randomly typed spaces.

-- Michael Chermside