This long discussion started with the question why the Go source is not
linted.
But I think the OP has answered his own question by providing us with a
list of 963 places
where the linter has decided that the code is deficient.
But what is notable, is that he has not given a single example where any of
these 963 warning has any value.
He has not taken even one of these warnings and show how "fixing" it leads
to better code.
411 of these warnings are for functions which are longer than the 150 lines
which are "allowed".
So I would ask: "allowed by whom?"
I am a big fan of short functions, as are the authors of the Go standard
library. But surely the optimal length of a function depends
on the context. I am not too bothered, about the length of functions in the
output of code generation, for instance. And I am OK with
code with a very regular structure - like a switch statement handling many
cases to take many lines.
Some of these linters do seem to be quite bureaucratic - imposing arbitrary
rules irrespective of whether they make sense in the actual context.
Code written in corporations (because it usually is in corporations) where
these linters are imposed, have a particular smell, with all kinds
of convolutions and ugliness designed to appease the linter.
If you see code where every line begins with
_, _ =
Or where you always see
defer func() { _ = res.Body.Close())()
rather that
defer res.Body.Close()
you know that this is the product of a programmer toiling under the
dictates of a linter.
Because if you are discussing some code with a knowledgeable reviewer, you
can defend your decisions.
You can explain why writing to a byte.Buffer can not fail (unless we are
out of memory, in which case any error
handling will fail too). But if you are told off by a linter, there is no
appeal. The linter has no discretion.
It is not open to discussion. It will not consider your arguments. Your job
is to do what the linter tells you.
Because the linter is always right. Because the computer is always right.
And you, as a mere human, are always wrong.
I would say that go vet is an exception - its warnings almost always point
to real problems in the correctness of code,
or unnecessary complexity. I often also run staticcheck on my own code. It
often makes useful observations, some of which
lead to useful changes. But beyond these two, linters often do more harm
than good. One very high quality linter with
few false positives is far more valuable that a large number of linters
which make nonsensical complaints.
golangci_lint is particularly bad in this respect - making it easy to run
loads of low quality linters, which cry wolf all the time and
train programmers to ignore warnings.
So I would appeal Ian and the rest of the Go team, to resist the pressure
to adopt these "great linters" - not to invest months of work
"fixing" these 963 "problems" identified by these linters. And focus on
carrying on doing what you are doing - producing,
rocks solid releases, well thought out enhancements, and code which can
serve as a template we can all emulate
to produce good, clear, idiomatic code.
On Tuesday, 13 December 2022 at 22:18:14 UTC marc...@gmail.com wrote:
> 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 <ia...@golang.org>:
>
>> On Tue, Dec 13, 2022 at 2:31 AM Brian Candler <b.ca...@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...@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/59fb5c6e-346c-4a3a-b1b4-b59b3b3510a2n%40googlegroups.com.
