I have no complaints, let me be clear about that. Just advice, for all I've learned in my cariere is that maintenance is happening more than the first version of something creative. But I've still got hope that one day I might understand some complex coding that I didn't write myself.
I'm happy to help, if an author of something "complex" can guide me. The only thing I can do now, is be a messenger. Op di 13 dec. 2022 om 20:52 schreef Ian Lance Taylor <i...@golang.org>: > 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 a topic in the > Google Groups "golang-nuts" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/golang-nuts/MM3W5oNw4-0/unsubscribe. > To unsubscribe from this group and all its topics, 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 > . > -- 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/CADBSaR3U11nDPwHZcSiV7R%3DTtndjUycO_ir76h-R5OjJWxGOAA%40mail.gmail.com.
