You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
var (
// LZW implements stream compression using the Lempel-Ziv-Welch (DCLZ)// compressed data format.LZWMethod=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.
The text was updated successfully, but these errors were encountered:
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: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 toNew
. 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.
The text was updated successfully, but these errors were encountered: