Goto (Posting On Python-List Prohibited)

bartc bc at freeuk.com
Sun Dec 31 09:20:09 EST 2017


On 31/12/2017 12:41, Chris Angelico wrote:
> On Sun, Dec 31, 2017 at 11:33 PM, bartc <bc at 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



More information about the Python-list mailing list