I totally understand that you put the ball back to me. My message is not to blame anybody and I think I didn't do that. People might be offended, but I'm just the messenger. The trick is, if we want software to survive, we should always check if it is understandable and maintainable and that is my message. The people who were willing to write solutions for complex problems are really awesome, because they also made Go the way it is today. But what happens if such a person is not able to do that anymore? Would others still comprehend what the original author had meant to do? We can be ahead of that, by looking at useful insights, like code complexity or number of lines that will give us hints about what could be improved.
I've said before, I want to help, but won't touch overly complex code. Because for me it's a waste of time understanding the code, while the original author can probably fix it in a breeze. (This is why linting regularly is so important: it will warn the author something is off.) I really hope nobody is offended and keeps up the good work. Op di 13 dec. 2022 om 11:31 schreef Brian Candler <b.cand...@pobox.com>: > I'd say that in an entire programming language and runtime environment > like Go, there is much which is inherently complex. Just think about > things like garbage collection <https://blog.golang.org/ismmkeynote> and > asynchronous preemption. A linter which creates dumb metrics like "number > of lines of code in a function" is unable to appreciate the semantics of > what is required to perform the job. > > Also consider that what you are saying *could* be construed as an insult > to the incredibly clever and dedicated people who have worked on this for > years. The implication is "you're not doing a very good job", or "why > didn't you think of using a tool like this?" (duh!) > > 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. > > (*) Even marginal performance regressions are going to hurt somebody > somewhere. There's much history in github issues that is worth reading - > just search for "bench" or "benchmark". > > On Tuesday, 13 December 2022 at 08:48:34 UTC marc...@gmail.com wrote: > >> Ok, I made a list with functions that are hard to understand because of >> the complexity. This is a calculated cognitive code complexity, but it >> serves me quite well when doing code reviews. >> The author of such a function might think that it's pretty easy to >> understand, but code complexity is how others look at code. >> (code ideally is maintainable by others as well) >> >> Following the "Go Style Guide", it should have Clarity, Simplicity, etc. >> >> I've put the threshold at 25 (which I normally have at 12). So everything >> above a complexity of 25 is reported. >> >> I also think that functions with a higher number of lines are also harder >> to understand, maintain etc. >> I've put the threshold at 150 (which I normally have at 50). So >> everything above 150 lines is reported. >> >> Both lists are attached, but what should I do with them? >> >> >> >> >> Op zo 11 dec. 2022 om 21:42 schreef Ian Lance Taylor <ia...@golang.org>: >> >>> On Sun, Dec 11, 2022, 2:03 AM Marcello H <marc...@gmail.com> wrote: >>> >>>> Ok, but does my answer really matter? Because in the end it's what any >>>> linter will tell us about the software. >>>> And since it is not hard to do, my suggestion always is to make use of >>>> some of the great linters that exist. >>>> >>>> In a new project I always start off with all the linters (in >>>> golangci_lint) active, and then deactivate the ones that I don't want. >>>> You can also do it the other way around, just a matter of "how to begin >>>> with linting". >>>> The advantage of using some linter would be that it is also a kind of >>>> quality fixation on the code. >>>> Perhaps deciding on which linter(s) to use at first and then slowly >>>> "inject" more. >>>> >>>> This post is not about finger-pointing btw, because if needed, I would >>>> offer my help with this. >>>> But I won't touch the functions with the high cognitive complexity ;-) >>>> >>> >>> We do use a linter on the Go standard library: go vet. When some change >>> in go vet causes it to report errors in existing code, we fix them. >>> >>> 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/9d9147b0-3c4c-4be2-ac49-43e0dd13aac0n%40googlegroups.com > <https://groups.google.com/d/msgid/golang-nuts/9d9147b0-3c4c-4be2-ac49-43e0dd13aac0n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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/CADBSaR37649PXvrY6SKvJ_R7Xipt%2BzSs2mcoOM53%3DAe9dfuJCg%40mail.gmail.com.
