> But perhaps I'm just a sucker for quality and maintainability and I'm
barking up the wrong tree.
I don't think that you will find many people here who don't think that code
quality and maintainability
are important.
But I would disagree with the implicit assumptions that
code that "passes" a linter is of high quality
and that code that "fails" the linter is of poor quality
>From my limited readings of the Go source code, I would say that the Go
team's judgement of code quality is far beyond that
of any linter I have seen.
On Wednesday, 14 December 2022 at 23:07:24 UTC marc...@gmail.com wrote:
>
>
> 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 <amn...@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...@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/11483ec0-bd26-4b9d-b430-9da54c160f5cn%40googlegroups.com.
