Goto (Posting On Python-List Prohibited)

Ben Bacarisse ben.usenet at bsb.me.uk
Sun Dec 31 10:02:13 EST 2017


bartc <bc at freeuk.com> writes:

> 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.

I think there's a problem with that.  Standard C does not have them, you
said your language does not implement them properly and I think you are
new(ish) to Python.  What language did you try them in?  It may be that
it was overly complex in that language.  The idea is clean and simple.

> 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).

The suggestion was to use them to avoid gotos.  If duplicating is a good
idea (and it's a hard line to draw) then we are not talking about the
same cases.  Given the choice of "dragging in named functions" and
dragging in named blocks and gotos, I would choose the functions every
time.

<text removed>
-- 
Ben.



More information about the Python-list mailing list