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 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/9d9147b0-3c4c-4be2-ac49-43e0dd13aac0n%40googlegroups.com.
