feat: add ExcludeMethod options with default

[raeperd]

Changed

• Add filtering logic based on method signatures
• Add default method signatures for encoding/marshaling parts of standard libraries
  • Whitelist marshaler methods #7 (comment)
• Add Config, NewAnalyzer function
  • referenced alingse/asasalint
  • user can pass extra signatures in form of UnmarshalJSON(data []byte, v any) error

Considerations

• check only names not signature? name check can be added later, so check signature in this pr
• runWithFilter is good pattern? tried to be as simple as possible without custom structs

next todos

1. Add check for simple method name check, so that user can simply add name of methods
2. Add README for options

Fixes #7

[ldez]

The signatures of the SQL elements seem too "generic" (Value() (any, error)) and it can lead to false negatives (some methods will be ignored, but they should not).

I understand you are trying to create something strict and configurable, but I think the full signature approach is a bit overkill, at least as a first step.

For me, the option is a bit weird: either it is an exception, then it can be managed with the exclusions inside golangci-lint, or this a common interface, and then it should be integrated internally (if possible).

Also, the option can lead to false negatives: a signature can be the same between different methods but those methods are related to different structures.

For me, the first step could be to not provide options, and filter on method names only.

names := []string{
	"MarshalText",
	"MarshalJSON",
	"MarshalXML",
	"MarshalYAML",
	"MarshalBinary",
	"GobEncode",
}

for _, name := range names {
	if funcDecl.Name.Name == name {
		return
	}
}

This will reduce the majority of false positives, and for the other cases, classic exclusions for the type inside golangci-lint can be enough.

issues:
  exclude-rules:
    - path: myfile.go
      text: 'the methods of "Foo" use pointer receiver and non-pointer receiver.'
      linters:
        - recvcheck

---

If you want to add an option, I think something simple can be used: struct name + method name (ex: Foo.Value).
This is less "generic" but easier to configure for a user than the signature and more strict (0 false positives or negatives).

typeName := recvTypeName(funcDecl.Recv.List[0].Type)

func recvTypeName(r ast.Expr) string {
	switch n := r.(type) {
	case *ast.Ident:
		return n.Name

	case *ast.StarExpr:
		return recvTypeName(n.X)
	}

	return ""
}

---

It's also possible to create a mix of solutions:

• keep the signature approach for the internal exclusions
• use struct name + method name as a user option (with maybe a simple wildcard: *.MarshalJSON)

---

WDYT?

[raeperd]

@ldez
Thanks for the detailed review!

I agree that checking the method signature is somewhat overkill for most users.

The idea of struct name and method name configuration is a good one. It’s much more usable than the full signature approach. (Maybe we can add this to the next PR.)

I’ll fix this PR with the following changes:

• Check only the default method names in slices.
• Remove the Setting.ExcludeMethod option and leave the NoBuiltinExcludeMethod option.
• Remove the Value function from the default.

[raeperd]

Applied review in b0ba9d3

[raeperd]

@ldez
Can we merge this now? lgtm

[ldez]

LGTM