refactor: make config options be consistent with the cli style

[ttys3]

simplify Config, make it consistent with the cli style

1. when users using the cli tool could just using a simple rule files,
   there's no reason to make users in other tools config the linter in a harder way.

2. map[string]struct{} is not a good struct for config file like json, yaml etc.

for example in yaml people will force to config like this:

- a: {}
- b: {}
- c: {}

but the whole thing they wanted is just:

- a
- b
- c

[codecov]

Codecov Report

Merging #22 (f5e5cd7) into master (ec4e3b8) will decrease coverage by 0.49%.
The diff coverage is 87.50%.

❗ Current head f5e5cd7 differs from pull request most recent head 2f4a6c6. Consider uploading reports for the commit 2f4a6c6 to get more accurate results

@@            Coverage Diff             @@
##           master      #22      +/-   ##
==========================================
- Coverage   91.08%   90.59%   -0.50%     
==========================================
  Files          10        6       -4     
  Lines         303      287      -16     
==========================================
- Hits          276      260      -16     
+ Misses         19       17       -2     
- Partials        8       10       +2     

Impacted Files	Coverage Δ
internal/rules/rules.go	95.49% <ø> (ø)
staticrules.go	45.45% <ø> (ø)
loggercheck.go	86.08% <79.31%> (-2.81%)	⬇️
internal/sets/string.go	100.00% <100.00%> (ø)
options.go	100.00% <100.00%> (ø)
cmd/loggercheck/main.go
plugin/plugin.go

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[timonwong]

2. map[string]struct{} is not a good struct for config file like json, yaml etc.

The config is not intended to used as config file.

[timonwong]

Though simplify Config struct for easier integration is good.

For golangci-lint, they have their own config struct styles, so there must be a struct conversion in between:
golangci/golangci-lint#3144

[ttys3]

even not intended to used as config file, even it is not for end user.

when the thing can be []string, why would we let people construct a map[string]struct{} ?

I know golangci-lint has its own config file or struct.

I mean, for Developer Experience (DX)

map[string]struct{} is an internal struct we use in loggercheck.

something like []string is we expose to the user (a developer or an end user)

[timonwong]

even not intended to used as config file, even it is not for end user.

when the thing can be []string, why would we let people construct a map[string]struct{} ?

I know golangci-lint has its own config file or struct.

I mean, for Developer Experience (DX)

Yes, it's good to use string slice over sets

[ttys3]

there's another thing, since we parse the rules our self, so there's failure.
I think we should change func NewAnalyzer(opts ...Option) *analysis.Analyzer to

func NewAnalyzer(opts ...Option) (*analysis.Analyzer, error)

then we can let the caller to determinate whether to panic or print an error message

[timonwong]

there's another thing, since we parse the rules our self, so there's failure. I think we should change func NewAnalyzer(opts ...Option) *analysis.Analyzer to

func NewAnalyzer(opts ...Option) (*analysis.Analyzer, error)

then we can let the caller to determinate whether to panic or print an error message

I think we can move those parts in run(). So we can process flags & config in a more consistent way. (Since we cannot add hooks for the global fags)

[ttys3]

and also, loggercheck.WithConfig could split to:

loggercheck.WithDisable and loggercheck.WithRules,

we do not need to expose an Config struct for developers since ourselves actually not using that

[ttys3]

it is better not move those to run()

because run() will make those run multi times and event concurrently (if I'm not wrong with this)

thus, we will need introduce sync.Once

I do not think this is a good idea

keep it in the NewXXXX construct is reaonable

[timonwong]

because run() will make those run multi times and event concurrently (if I'm not wrong with this)

it will b called only once (guarded in a sync.Once)

[ttys3]

I made a second commit, PTAL @timonwong

274a646