How an editor can help with block nesting (was Re: How coding in Python is bad for you)

[Steve D'Aprano]

On Wed, 25 Jan 2017 08:19 am, Chris Angelico wrote:

> I kinda like the idea of showing what the innermost active block
> heading is for any given line of code. That would be fairly
> straight-forward: scroll up till you find a non-blank line with less
> indentation than the one you're on, and put a marker there. The
> nearest equivalent I have is a feature that one of my cow-orkers asked
> for once: a Python version of "jump to nearest brace". I bound it to
> Ctrl-E, and played with the feature, but never really found it useful
> - it was of mild value but I could generally eyeball it just as
> easily. 

Indeed. Good programming practice suggests that your block should ideally be
under half an dozen lines and certainly less than a full screenful. If you
need a command to jump to the top or bottom of the block, your blocks are
too big and need refactoring.


> Would be curious to see how it works with a colour highlight 
> rather than an active "go to the top of this block" keystroke.
> (Bikeshed: should _every_ active block heading be highlighted, or just
> the innermost one? If you're inside a function, a loop, and a
> condition, should the 'def', 'for', and 'if' lines all be
> highlighted?)

I actually don't see the point.

For an experienced coder, you already have all the clue you need to see the
block structure: the indentation level.

(If you are indenting by a single space, or even two spaces, you're probably 
hamstringing yourself and hurting your ability to recognise structure at a
glance.)

Adding an extra colour cue to duplicate the information given by indentation
just adds to the noise level of code. But if you were to do the experiment,
I'd *only* colour the currently edited block, by marking the margins with a
subtle colour. You know how many GUI editors highlight the current line
with a faint colour? Something similar. You could make the colour different
for each block, I guess, if you wanted to be fancy.


> With my JavaScript students, the greatest help is probably a keystroke
> beautifier. You edit your code with sloppy indentation, and then bam,
> it reindents for you. 

Really? I wouldn't want that, or find it helpful to type badly formatted
code. I would want one of two things:

(1) Indentation is up to you. You either get it syntactically right, or the
code won't run, like Python. That teaches you to get the indentation right
through negative reinforcement.

Of course merely getting the indentation syntactically correct doesn't mean
it is *semantically* correct, but the editor or compiler doesn't know what
you mean, only what you say. If you cannot get the syntax right, you can't
hope to communicate to the compiler. So learning to get the syntax right is
a necessary first step to learning to program.


(2) Or the editor won't let you enter sloppy indentation in the first place.
This teaches you good indentation by example.

Every time you hit return, the editor automatically indents as needed. If
you mistakenly change the indentation (or fail to change the indentation
when needed), then when you hit return on that line (or any other editing
command that moves to another line), the editor either fixes the
indentation for you, if it can, or flags the line as a syntax error if it
cannot determine the right thing to do.


For example, suppose I already have this, where | is the current text
insertion point:

    def func(a, b):
        if condition:
            spam() |

I hit ENTER, and the editor automatically indents to the current block
level. There's nothing new about that, most editors already do this:


    def func(a, b):
        if condition:
            spam()
            |

But now I type something which cannot possibly be indented there:

    def func(a, b):
        if condition:
            spam()
            elif something: |

and hit ENTER again. There's nothing ambiguous about this, and the editor
could (and should?) re-indent the elif line, giving this:

    def func(a, b):
        if condition:
            spam()
        elif something:
            |

In other words, with the second scenario, you can never have more than one
mis-indented line at a time during the normal course of editing. (At least
not without really working to defeat the editor.)




-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.