-
Notifications
You must be signed in to change notification settings - Fork 46
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Create linter configuration and address found issues #10
Conversation
.golangci.yml
Outdated
|
||
prealloc: | ||
# XXX: we don't recommend using this linter before doing performance profiling. | ||
# For most programs usage of prealloc will be a premature optimization. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@rdner Looking at the comment we might want to remove it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Every comment was just copied from the official doc. And it makes sense to me. By default, we should pre-allocate but it does not mean that it's required.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not a huge fan of this one either, I'm not a huge fan of premature optimisations. I'm just wondering if it can get noisy.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe if it's known one should always set capacity when allocating, for example:
b := map[string]interface{}{}
a := make([]string, 0, len(b)) // vs `var a []string`
for key := range b {
a = append(a, key)
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I removed the comment that it would not scare anyone. I'd like to keep the linter though unless everyone are oppose it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't mind this, it's not an optimization that makes the code harder to read. If anything it makes the allocation more obvious.
I have seen preallocating like this make a big performance difference in frequently used code that creates small slices/arrays. The underlying array doubles when there's not enough capacity, which happens more frequently if the slice was empty and stays small (per "Growing Slices" in https://go.dev/blog/slices-intro)
# Enable to require nolint directives to mention the specific linter being suppressed. Default is false. | ||
require-specific: true | ||
|
||
staticcheck: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
NIT: It would be nice to have the 1.17
to be populated by the .go-version
file, could be done with the mage task.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, that would mean we make a template configuration that we build on CI right before we run the linter.
These versions are configurations for built-in linters, so every built-in linter (plugin) is free to choose how they configure themselves and they don't seem to support .go-version
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the long run it would be nice to have it reading from .go-version
so we don't need to remember to update this configuration file as we change our Go version.
Because we're most likely running it with mage, I see no issue on adding this automation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@rdner This shouldn't be a lot of effort, we have already code generation. There is a make update
task that generates the configuration files from templates and other generated files. That make update
comment is run on every build, if git status
detects new files or modified files it will fail the build.
So the workflow would be like this.
- Update
.go-version
- run
make update
- Push PR with the updated linter information and the updated go version.
- We have an automated task that does this [automation] Update go release version 1.17.7 fleet-server#1143
But on the other side we will have 1.17 for some time and 1.18 for quite some time, I just hate having multiple files to updates we still have too much and removing the human in the operation is always a good thing and having multiple go repository that just work the same would save us time.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ph This PR already has a ton of comments, I'm not going to implement it here but I can take it as my next step.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Change looks to me, the number of linter feels a bit overwhelming, adding a comment to remove the prealloc
since we haven't done any performance analysis, yet and we with the architecture change it might be premature to worry about it. If possible we should remove the 1.17
magic number from that files, we can populate it from the .go-version
file.
To reduce the noise and make the run faster, it would be nice in ci if the check was only run on the added or modified files. This would allow us to enforce it from day 1, and incrementally improve the code as we go.
So far, I would be +1 to share the same across all of our repositories.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great job @rdner !!
One little detail, once the PR is finalised, what about sorting the liners alphabetically? I feel it makes reading easier.
Thanks for proposing this @rdner. There is a lot to deal with to get this enabled it seems. |
sh(label: 'lint', script: ''' | ||
go mod tidy && git diff --exit-code | ||
gofmt -l . | read && echo "Code differs from gofmt's style. Run 'gofmt -w .'" 1>&2 && exit 1 || true | ||
''') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
go mod tidy
has been moved to the magefilegofmt
is now included into the new linter
sh(label: 'Mage check', script: 'mage check') | ||
sh(label: 'Go vet', script: 'go vet ./...') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is now included into the new linter.
@@ -380,7 +384,12 @@ func (r *Rotator) closeFile() error { | |||
} | |||
err := r.file.Close() | |||
r.file = nil | |||
return errors.Wrap(err, "failed to close active file") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wrap
returns nil
if the err == nil
, fmt.Errorf
does not, so had to adjust.
Since this PR is already quite big, I'm going to create a follow-up PR where I will add support for:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🎉
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know it has been merged, but I'm still submitting it so I don't lose all I've written :P
This PR is to propose the linting configuration that we are going to re-use for new repositories.
Also, all the currently found linting issues are fixed in this PR which can give an idea what kind of common issues we have now in our code and which the linter finds.
Closes elastic/beats#30150