Re: Perl Best Practices

Just to add something I don't see mentioned yet:

I believe the similarity to "goto LABEL" in some languages, which generates spaghetti code which is hard to read and maintain, was possibly behind this line of questioning

Perl's next, last, and redo are much more akin to C's continue and break than they are to goto. So unless your colleagues have issues with the former two, tell them not to worry :-) IMHO, labeled blocks, including loops, are basically the much, much better version of goto, in that they allow complicated flow control to be implemented in a much cleaner way. Also, IIRC, their behavior in regards to the stack is much cleaner than with goto. There are three cases that I can think of right now where people try to justify gotos:

Flow control in loops - that can be much better implemented with the aforementioned next, last, and redo.
Control constructs where we have much better solutions nowadays, I'm thinking of On Error Goto ... or everyone's favorite, On Error Resume Next. (Nowadays of course try/catch.)
Really low-level stuff, like IIRC I once goto'd into an assembly routine from C, which of course doesn't apply in Perl.

And then there's the spaghetti code artists that are the reason that goto has such a deservedly bad reputation.

Anyway, as for the general question, I use labeled loops much like tobyink showed: in nested loops, and with sensible names (e.g. "last LINE" and "next FILE" are great to understand). I almost never have more than two nested loops, at a max three (everything else is in subs or methods), and the other thing is that I try to keep my loops short, under a page if possible, so that one doesn't lose an overview of the control flow. When used like this, including in the example you showed, I think labels are a Good Thing.

Comment on Re: Perl Best Practices - Loop Labels Select or Download Code

Replies are listed 'Best First'.
Re^2: Perl Best Practices - Loop Labels by jcb (Parson) on Apr 17, 2020 at 03:20 UTC
There is at least one very good use of `goto` in C: error handling. In a function that allocates and initializes complex structures, an earlier allocation can succeed but a later allocation fail. When this happens, the earlier allocation must be released before returning `NULL` to avoid leaking memory. `something * alloc_something(void) { something * ret = malloc(sizeof(something)); if (ret == NULL) goto out; ret->another_thing = alloc_another_thing(); if (ret->another_thing == NULL) goto out_free_ret; return ret; /* error exits */ out_free_ret: free(ret); out: return NULL; }` [download] I learned this style from reading Linux kernel sources and it makes error handling much more readable and maintainable by keeping the successful path and the error path separate. While this example was very simple, this pattern especially shines when more than one allocation must be backed out before returning failure because it avoids duplicating the code to release the earlier allocations.	[reply] [d/l] [select]
Re^3: Perl Best Practices - Loop Labels by talexb (Chancellor) on Apr 19, 2020 at 19:41 UTC
Interesting .. yet I can see a fairly simple way to restructure this C code, without either of the `goto` statements .. something * alloc_something(void) { /* Make two malloc requests. Insure both succeed; return allocated memory, if any. Three possible logic paths: 1. First malloc fails, and we are done. 2. First malloc succeeds, second malloc fails: free the first allocated block, and we are done. 3. First and second mallocs succeed, and we are done. / something ret = malloc(sizeof(something)); /* Did the first request succeed? / if (ret != NULL) { ret->another_thing = alloc_another_thing(); / Did the second request fail? */ if (ret->another_thing == NULL) { free(ret); ret = NULL; } } return ret; } [download] Alex / talexb / Toronto Thanks PJ. We owe you so much. Groklaw -- RIP -- 2003 to 2013.	[reply] [d/l] [select]
Re^4: Perl Best Practices - Loop Labels by jcb (Parson) on Apr 20, 2020 at 03:34 UTC
Yes, and that was the pattern I used before finding the "`goto out`" pattern in the Linux kernel sources. For simple cases, there is little difference, but even with two allocations, a problem begins to appear: compare the indentation depth between the two solutions and consider what happens when they are extended to include a third or fourth allocation. The "`goto out`" pattern also takes up far less vertical space for error handling in the main code path, like the common `open ... or die ...` idiom in Perl. When the error path is also branchless, simply releasing some subset of allocated objects and returning NULL, the "`goto out`" pattern has the advantage of cleanly grouping the error path into one block (with many entry points) after the main code path, allowing both to be examined separately. I should probably include a reminder here that this pattern is useful in C, but Perl has better ways of handling error exits because the runtime manages memory, unlike in C. I am unsure if I have ever used `goto LABEL` in Perl.	[reply] [d/l] [select]