Navigation Menu

Skip to content
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

x/lint: type omission lint fires even when type is necessary for documentation purposes #26274

Closed
SamWhited opened this issue Jul 8, 2018 · 3 comments

Comments

@SamWhited
Copy link
Member

SamWhited commented Jul 8, 2018

I wasn't sure whether to file this as a bug or a proposal, but I would like to remove or disable-by-default the type omission lint. It is the most common false positive I have, and fires often even when the type is necessary for the identifier to show up in the correct place in the documentation.

For example, in mellium.im/xmpp/compress this lint fires for the following:

var (
    // LZW implements stream compression using the Lempel-Ziv-Welch (DCLZ)
    // compressed data format.
    LZW Method = lzwMethod
)

However, without the type, the list of supported compression methods does not show up under the Method type. Instead it shows up at the top of the package level docs and it is no longer that these are existing methods that can be passed to New. In such a small package it doesn't really matter, but in larger packages it can be absolutely necessary to group values under their type.

This isn't technically a problem with Go code (which is what the linter is made to find), but I do think the lint is often encouraging bad practice and unreadable docs, which seems like a good enough reason to get rid of it since it doesn't really provide any benefit that I can see but does have this down side.

@gopherbot gopherbot added this to the Unreleased milestone Jul 8, 2018
@agnivade
Copy link
Contributor

agnivade commented Jan 7, 2019

Hey @SamWhited - I think golint issues are tracked in its own repo. Should we move it there ?

@SamWhited
Copy link
Member Author

oops, my mistake, I thought all the external tools repos were being moved here. Feel free to move it, or I can recreate it; whatever is easiest.

@agnivade
Copy link
Contributor

agnivade commented Jan 7, 2019

I think it's better if you move it so that you have ownership of the issue.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants