Sorry, but I didn't state (and so does the linter) that any code is
deficient.
Normal usage of a linter is not to satisfy a linter, but to do some basic
code review.
(Most new linters can skip certain code lines these days too.)

I know that  the number of lines in a single function is just a matter of
taste.
But I also know that a function with too many lines is also harder to
maintain.
If you study those functions that are "too long", you will find that it
could probably be split up in a more readable and maintainable way.

The only worry I have is that complex code is very hard to maintain,
perhaps only by a single person.
What happens if that person isn't available anymore? The best time to
maintain code to  a more maintainable version, is at the moment of creation
or not much later,
because only then it lives still "in the mind" of the creator. A linter can
help detect those "blindspots" of a developer and can point out where those
are.

With the new guidelines, one can expect to see the Go code as an example of
those guidelines.
(one of them being maintainable software)

Does anybody have to fix all of it now? Of course not, but perhaps when a
developer is touching one of those functions and understands what it does,
then it is still the ideal time to rewrite it a bit.

But perhaps I'm just a sucker for quality and maintainability and I'm
barking up the wrong tree.
I very much want Go to survive, so for me that means that people should not
be afraid to maintain parts of the code.
(and that's why I said not to touch all those high complexity parts,
because I find it highly confusing; so i'm not fit for that job.)

Op wo 14 dec. 2022 om 23:33 schreef Amnon <amno...@gmail.com>:

> 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 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/59fb5c6e-346c-4a3a-b1b4-b59b3b3510a2n%40googlegroups.com
> <https://groups.google.com/d/msgid/golang-nuts/59fb5c6e-346c-4a3a-b1b4-b59b3b3510a2n%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/CADBSaR2K7Rurd_SQc1%3Dt5CQPCaunv%3DX7d9zgmePu4m8xkDjfyg%40mail.gmail.com.

Reply via email to