golint doesn't require comment for "exported" methods of unexported types

[jim-minter]

In the following example, golint does not require a comment on foo.Bar(). This decision is implemented at https://github.com/golang/lint/blob/master/lint.go#L819-L821. I think golint should require a comment, either for all "exported" methods of unexported types, or for methods of unexported types which constitute an exported interface, or for each method indicated in an exported interface definition (i.e. under type Foo interface).

package test

// Foo -- this comment is required by golint
type Foo interface {
    Bar()
}

type foo struct {
}

// Bar -- this comment is *not* required by golint
func (f *foo) Bar() {
}

// NewFoo -- this comment is required by golint
func NewFoo() Foo {
    return &foo{}
}

[dsnet]

Hi. I believe this is working as intended. If you were to view this package on godoc, you'd see something similar to the following:

PACKAGE DOCUMENTATION

package foo
    import "."

TYPES

type Foo interface {
    Bar()
}
    Foo -- this comment is required by golint

func NewFoo() Foo
    NewFoo -- this comment is required by golint

Precisely because the foo type is unexported, the foo.Bar method never gets shown on the documentation page. Thus, lint does not require the user to document that method. That being said, it may make more sense to have the Bar method defined in the Foo interface to require a comment.

[ronator]

Ouh, I learned something. THX

[josephholsten]

@jim-minter @dsnet can this be closed?

[jim-minter]

I do think there is something to fix here: AFAICS golint currently does not require Bar() to be documented, either in the interface definition or in its implementation on a private type. But NewFoo().Bar() could be called externally. Perhaps the answer is requiring Bar() to be documented in the interface definition.

However it may also be that changing this is considered too intrusive, or that it should have a switch when switches on golint are not wanted, etc., in which case maybe it'll never be implemented.

[mvdan]

Thank you for submitting this issue! As per golang/go#38968, we are freezing and deprecating golint. There's no drop-in replacement to golint per se, but you should find that Staticcheck works well in encouraging good Go code, much like golint did in the past, since it also includes style checks. There's always gofmt and go vet too, of course.

If you would like to contribute further, I'd encourage you to engage Staticcheck's issue tracker or look at vet's open issues, as they are both actively maintained. If you have an idea that doesn't fit into either of those tools, you could look at other Go linters, or write your own - these days it's fairly straightforward with go/analysis.

To help avoid confusion, I'm closing all issues before we freeze the repository. If you have any feedback, you can leave a comment on the proposal thread where it was decided to deprecate golint - though note that the proposal has been accepted for nearly a year. Thanks!