Hi Kurtis, > Is the code after the "end" label ever going to be more complicated than a > simple "return err"? If not then I don't see the point of the goto statements.
Yes, very often. I could show examples but don't want to trigger bike shedding. If you want to see some I'll be happy to send off-list. > Also, since you named the return value you can simply do "return" rather than > "return err" (personally I'm not a fan of bare returns that implicitly return > the named return parameters). I started using this pattern to avoid multiple return statements which can be problematic when you want the debugger to stop before a function returns. If you miss breakpointing a return you can waste time chasing your tail. Most recommend against naked returns so I prefer one set of return values instead of many repeating ones. I have also found other beneficial reasons to use the pattern than just the debugging concern, which I can discuss off-list if you like. > That function can be ten lines (25%) shorter Length is one useful metric, but there are other metrics I consider too. > I would argue would be clearer since the reader doesn't have to look at what > follows the "end" label. The pattern has an `end:` label always at or near the only return in the func, and (almost) never any other labels so a reader need not look for it after recognizing the pattern. -Mike > On Aug 26, 2023, at 10:51 PM, Kurtis Rader <kra...@skepticism.us> wrote: > > On Sat, Aug 26, 2023 at 6:02 PM Mike Schinkel <m...@newclarity.net > <mailto:m...@newclarity.net>> wrote: > OTOH, in my quest to provide the simplest example I could, I provided an > example that does not expose the use-case I was interested in exploring, > unfortunately. > > Let me instead present some real code from my current project, specifically > the variable declarations on the lines 35-36 of the `Process()` method of > `*FileProcessor` where the variables declared at the top are not referenced > after the label: > > https://github.com/newclarity/wpfr/blob/88d1289a90646f59ec4233eed0e421f1eae36332/pkg/wpfr.go#L34-L75 > > <https://github.com/newclarity/wpfr/blob/88d1289a90646f59ec4233eed0e421f1eae36332/pkg/wpfr.go#L34-L75> > > Is the code after the "end" label ever going to be more complicated than a > simple "return err"? If not then I don't see the point of the goto > statements. Also, since you named the return value you can simply do "return" > rather than "return err" (personally I'm not a fan of bare returns that > implicitly return the named return parameters). That function can be ten > lines (25%) shorter and I would argue would be clearer since the reader > doesn't have to look at what follows the "end" label. > > -- > Kurtis Rader > Caretaker of the exceptional canines Junior and Hank -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/3495CCD1-6509-4027-9F2B-082B205E1568%40newclarity.net.
