-
Notifications
You must be signed in to change notification settings - Fork 3
Build flags and other options #4
Comments
Or perhaps we could even make this package aware of all the possible options. The question then is - could a linter have an option that is specific to it, and not applicable to most linters? I don't know the answer to that question, but I think assuming that there aren't could limit some linters. |
Actually, whether or not tests should be included happens earlier, in the |
I'm not convinced yet why
This sure can happen. On the other hand,
Agreed. |
This was my initial idea, as I'm a big fan of linters that "just work".
Thought of this one too, but IMO it's too chaotic. For example, what if two linters separately accept the same flag name, meaning different things?
I think this is a valid option just like the first one. It all depends on whether we want the interface and var linters = [...]struct {
name string
checker lint.Checker
}{
{"unparam", &unparam.Checker{}},
{"interfacer", &interfacer.Checker{}},
} It could just as well be, with no changes to the interface: var treshold = flag.Int(...)
[...]
{"interfacer", &interfacer.Checker{Treshold: *treshold}}, |
Of course, each And we should probably encourage something like Rob Pike's and Dave Cheney's option funcs: https://dave.cheney.net/2014/10/17/functional-options-for-friendly-apis |
That wouldn't happen, because it would go something like: $ metalint -pass linterA:samename:value1 -pass linterB:samename:value2 ... Still, this should probably be simpler. |
Ouch, that's verbose. Even with that, it would still be somewhat confusing. I think we should let the caller decide what to do when calling the constructors with the options. They can follow each linter's flag names and use a prefix system like you suggested too, but I'd likely not do that for the |
Now that |
Quite a number of linters accept flags that change their behavior. The most common case is whether or not to load test files via
go/loader
.Others include build tags, or what Go versions to check against (e.g. for new
std
stuff).With the current API, none of those are possible. Some ideas:
The text was updated successfully, but these errors were encountered: