On Tue, Dec 13, 2022 at 2:31 AM Brian Candler <b.cand...@pobox.com> wrote: > > With that in mind, I'd respectfully suggest that your starting point should > be to pick one of these "over complex" functions, understand it fully, and > rewrite it in what you consider to be a simpler/clearer way which does not > break any functionality, *and* which does perform any worse than the original > code (*). Then you can submit it as a pull request for review. Rinse and > repeat.
With respect, I'm going to suggest not doing that. If code is working correctly, then changing it, even to simplify it, may cause it to stop working correctly. In fact, this is more likely to happen if the original code is complex. The best approach to complex working code is to only change it if there is a good reason to do so: because the requirements have changed, or because there is some way to make it run measurably faster, or because it is a regular source of bugs. Also I hope we can all agree that blind adherence to any specific definition of complexity is misguided. For example, a function that is basically a big switch statement with a bunch of cases is often easier to understand as a single function rather than a collection of different ones. I hope we can all agree that reducing the number of code complexity reports to zero is not a goal. I'll note that the list of complaints here seems to me to be biased toward breaking up large functions into smaller functions. In some cases that can make the code easier to understand. In other cases it does not. Judgement is required. Ian -- 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/CAOyqgcXGWbAEVy89cMFXmwS-%3DPYZ%3D6NEYQ-i6NnzyfMmZ8W7MA%40mail.gmail.com.
