On 31/12/2017 12:41, Chris Angelico wrote:
On Sun, Dec 31, 2017 at 11:33 PM, bartc <b...@freeuk.com> wrote:
On 30/12/2017 23:54, Chris Angelico wrote:
I've written code that uses dirty tricks like that to avoid
duplication. It's at least as much of a problem as actual duplication
is. Generally, the 'goto' solution results in subsequent programmers
(such as my future selves) staring at the code for 30-60 seconds to
figure out what it's doing. I don't like to do that to myself, much
less to people I actually admire and respect.
The problem is having to stare at the code for even longer to figure out the
even dirtier tricks you had to use to avoid gotos.
Dirtier tricks like... named functions?
I like to write clean and readable code. If I thought introducing
functions, whether local or not, as a way of avoiding goto was worth
doing, I would do so.
So in this case I disagree with dragging in named functions and
introducing an extra level of control flow just to avoid duplicating
half a dozen lines of code. I would just duplicate those lines (with a
comment that they have to match the other set so that they are
maintained in sync).
For other uses of goto, I've introduced (not in Python or C but my own
stuff) features to avoid the need some of those uses.
For example, extra loop controls, and loop controls that work with
nested loops. I've also experimented with a feature intended purely to
get to common clean-up code, but that had little advantage over using
goto other than not writing 'goto', and thus avoiding some of the stigma
(but you will also know it will do a one-off forward jump to a common
point).
(Actually, none of my code ever needs to use 'goto' anyway, as I can
also write it as 'go to'. That's effective if anyone does a 'grep' on my
code looking for 'goto' instances...)
--
bartc
--
https://mail.python.org/mailman/listinfo/python-list
