On Wed, Jan 25, 2017 at 6:31 AM, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> I'm not talking about detecting errors -- that's for the programmer --
> but the editor can help the programmer to be sure they wrote what they
> meant by doing things like matching brackets and auto-indenting code in
> {}s. (I'm replying to a post about JavaScript which has {}s.)
>
> The trouble is that I've been programming for so long that I can't
> remember what it's like to make block and/or indent errors. Obviously I
> make typos but they don't survive more than a few seconds. I hoped that
> Chris's students would provide an insight into how the tools do or
> don't help.
>
> In Python the editor could, for example, highlight the block you are
> typing in, so as soon as you leave the body of the 'if' it would stop
> being marked and the containing code would be highlighted. Just moving
> the cursor up and down would show you what block everything is in. I
> don't know if any editors help like this -- that's part of my reason to
> ask.
This is a huge topic, and worthy of its own thread.
I've toyed with a lot of different editors myself, and in the end, I
actually found that features like this are less valuable than having
an editor that's light on its toes and responds snappily even on
lower-end hardware (and I like using the same editor with the same
configs on all my systems). so I'm using SciTE. The most common editor
among my students is probably Sublime, followed by Atom, and they have
fairly similar feature sets.
Ultimately, programming is a messy business. You start out with an
imperfect idea of what you want, and progressively refine from there.
So anything that lets you "sketch" your code more easily is a good
thing. I think we can all agree on that part, right? It's just a
question of what _kind_ of help the editor gives.
The main two forms of help that I get or see from editors are:
1) Actually doing stuff for you, where it's 95% certain what you want
2) Visually showing you what your code is doing.
The first category includes stuff like auto-indentation (add an
indentation level when you have an open brace, or when there's a colon
ending the previous line), and the second category includes stuff that
highlights language keywords, or tells you about local vs global
names, or shows you where the matching bracket is for the one your
cursor's on.
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. 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?)
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. The trouble is that they can end up with code
where the indentation matches the braces, but *both are now wrong*.
I'd be very curious to see an "auto-bracket-closer" that adjusts the
brackets to match the indentation. Here's an example piece of
JavaScript - imagine this has been through a few rounds of editing:
function reducer(state=initial_state, action={}) {
switch (action.type) {
case 'FROBNOSTICATE':
let items = info_store.filter((item) => {
console.log("item:", item);
return action.frob == item.frobbability;
)}
console.log("Keeping:", items)
return {...state, frobbables: items}
}
default: break;
}
return state;
}
Now, I've deliberately made the indentation follow my intention, and
then messed up the brackets. An editor should be able to look at this
and pinpoint the places where the indentation changes unexpectedly,
and either automatically correct it, or raise an error (in the case of
the omitted open brace in the above example). I'd be curious to see
how well this works for people, particularly novices. But it'd have
to be implemented first :)
Python removes some of this by not using braces for block delimiters,
but you can still get the same phenomenon with nested list/dict
displays, function calls, etc. So the code would be identical, except
that a colon at the end of a line indicates indentation too.
Anyone want to code this into an editor and see how it performs?
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
