Re: [go-nuts] Linting

2022-12-14 Thread Amnon
> 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"

Fwd: [go-nuts] Linting

2022-12-14 Thread Marcello H
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

Re: [go-nuts] Linting

2022-12-14 Thread Amnon
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

Re: [go-nuts] Linting

2022-12-13 Thread Marcello H
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

Re: [go-nuts] Linting

2022-12-13 Thread Ian Lance Taylor
On Tue, Dec 13, 2022 at 2:31 AM Brian Candler 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

Re: [go-nuts] Linting

2022-12-13 Thread Marcello H
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

Re: [go-nuts] Linting

2022-12-13 Thread Brian Candler
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 and asynchronous preemption. A linter which creates dumb metrics like "number of

Re: [go-nuts] Linting

2022-12-11 Thread Ian Lance Taylor
On Sun, Dec 11, 2022, 2:03 AM Marcello H 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

Re: [go-nuts] Linting

2022-12-11 Thread Amnon
If you want, run any linters of your chosing on the Go standard library, go through the reports, and see if any are valid - which expose real problems, then feel free to report them here, or submit bug reports. On Sunday, 11 December 2022 at 10:03:21 UTC marc...@gmail.com wrote: > Ok, but does

Re: [go-nuts] Linting

2022-12-11 Thread Marcello H
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)

Re: [go-nuts] Linting

2022-12-10 Thread 'Dan Kortschak' via golang-nuts
On Sat, 2022-12-10 at 14:44 +0100, Marcello H wrote: > golangci_lint ... > > Op za 10 dec. 2022 om 13:17 schreef Brian Candler > : > > The question remains, which linter(s) are you using? golangci_lint is not really an answer to this question since it's just a collection of linters, many of which

Re: [go-nuts] Linting

2022-12-10 Thread Marcello H
golangci_lint and my own (for the cognitive code complexity) Op za 10 dec. 2022 om 13:17 schreef Brian Candler : > The question remains, which linter(s) are you using? > > -- > You received this message because you are subscribed to a topic in the > Google Groups "golang-nuts" group. > To

Re: [go-nuts] Linting

2022-12-10 Thread Brian Candler
The question remains, which linter(s) are you using? -- 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

Re: [go-nuts] Linting

2022-12-10 Thread Marcello H
I agree that not all linting is useful, but when I see certain outcome that is questionable, I would be investigating that a bit more if it was my code. For example: There is code that uses deprecated functionality, that could easily be changed to the newer version of that. There are: - lots of

Re: [go-nuts] Linting

2022-12-10 Thread Brian Candler
On Friday, 9 December 2022 at 19:09:34 UTC Ian Lance Taylor wrote: > 1) Linters are optional and opinionated, and it kind of matters which > linter you mean. And of course, go itself already comes with the grandaddy of all linters - "go vet ". -- You received

Re: [go-nuts] Linting

2022-12-09 Thread Ian Lance Taylor
On Fri, Dec 9, 2022 at 5:38 AM Marcello H wrote: > > Since we have great linters, I wonder why it seems that the Go source itself > isn't linted? > (Because when I do lint it, I see a lot of suggested improvement) 1) Linters are optional and opinionated, and it kind of matters which linter you

[go-nuts] Linting

2022-12-09 Thread Marcello H
Since we have great linters, I wonder why it seems that the Go source itself isn't linted? (Because when I do lint it, I see a lot of suggested improvement) -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop