是否可以使用Visual Studio Code的linter忽略特定的警告? [英] Is it possible to ignore specific warnings with Visual Studio Code's linter?

问题描述

我们公司正在考虑从Sublime转换为Visual Studio Code.

Our company is thinking about switching from Sublime to Visual Studio Code.

通过SublimeLinter，可以在首选项文件中使用ignore_match语句来忽略特定的警告.这样我们就可以隐藏误报，例如URL中的跟踪标签.

With SublimeLinter it's possible to use ignore_match statements in the preferences file to ignore specific warnings. This lets us hide false positives such as tracking tags in URLs.

我试图在VSC中找到等效功能，但无济于事.谁能告诉我这是否可以实现?

I've tried to find an equivalent function in VSC but to no avail. Can anyone tell me if this can be achieved?

谢谢

推荐答案

我认为您的linter的配置将非常特定于语言-这是Golang的答案，并且根据语言的不同，可能会有很大不同您正在使用.

I think that your linter's configuration is going to be very language specific - this is an answer for Golang, and it's probably going to be very different depending on the language you're using.

在VSCode中使用Golang，您可以设置要使用的短绒.有多种选择，包括(截至2018-10-31)gometalinter. gometalinter提供了--exclude标志，可用于忽略特定的警告文本.

Working with Golang in VSCode, you can set the linter that you use. There are several choices, including (as of 2018-10-31) gometalinter. gometalinter provides the --exclude flag that can be used to ignore specific warning text.

例如，我当前的项目有来自golint的以下警告:

For example, my current project has the following warnings from golint:

> golint ./...
internalapi/types.go:39:2: exported const Foo should have comment (or a comment on this block) or be unexported
internalapi/types.go:263:6: exported type Foo should have comment or be unexported
internalprovider/providerprovider.go:489:22: method Foo should be FOO
internalprovider/providerprovider.go:541:22: method Foo should be FOO
internalprovider/providerprovider.go:552:22: method Foo should be FOO
internalprovider/providerprovider_test.go:514:2: var Foo should be FOO
internalprovider/providerprovider_test.go:514:12: var Foo should be FOO
internalprovider/types.go:26:6: exported type Foo should have comment or be unexported
internalprovider/types.go:31:6: exported type Foo should have comment or be unexported
internalprovider/types.go:32:2: struct field Foo should be FOO
internalprovider/types.go:36:2: struct field Foo should be FOO
internalcfg/internalcfg.go:283:1: exported method internalCfg.Cfg should have comment or be unexported
internalsetup/internalsetup.go:47:29: error strings should not be capitalized or end with punctuation or a newline
internalsetup/internalsetup.go:65:29: error strings should not be capitalized or end with punctuation or a newline
internalsetup/internalsetup.go:73:29: error strings should not be capitalized or end with punctuation or a newline
internalsetup/internalsetup.go:249:21: error strings should not be capitalized or end with punctuation or a newline
internalsetup/internalsetup.go:266:21: error strings should not be capitalized or end with punctuation or a newline
internalsetup/internalsetup.go:281:21: error strings should not be capitalized or end with punctuation or a newline
internalutil/internalinput.go:49:1: exported function Foo should have comment or be unexported
internalutil/internalinput.go:54:1: exported function Foo should have comment or be unexported
internalutil/internalinput.go:70:1: exported function Foo should have comment or be unexported
internalutil/types.go:18:2: comment on exported const Foo should be of the form "Foo ..."
internalutil/types.go:20:2: exported const Foo should have comment (or a comment on this block) or be unexported
internalutil/types.go:36:2: comment on exported const Foo should be of the form "Foo ..."
internalutil/types.go:42:2: comment on exported const Foo should be of the form "Foo ..."
internalutil/types.go:47:2: comment on exported const Foo should be of the form "Foo ..."
internalutil/types.go:55:2: comment on exported const Foo should be of the form "Foo ..."
internalutil/types.go:61:2: comment on exported const Foo should be of the form "Foo ..."
internalutil/types.go:65:2: comment on exported const Foo should be of the form "Foo ..."
internalutil/types.go:70:2: comment on exported const Foo should be of the form "Foo ..."
internalutil/types.go:88:2: const Foo should be FOO
internalutil/types.go:97:2: const Foo should be FOO
cmd/launch_provider_instance.go:31:2: don't use ALL_CAPS in Go names; use CamelCase
cmd/launch_provider_instance.go:31:2: exported const Foo should have comment (or a comment on this block) or be unexported
cmd/launch_provider_instance.go:32:2: don't use ALL_CAPS in Go names; use CamelCase
cmd/launch_provider_instance.go:33:2: don't use ALL_CAPS in Go names; use CamelCase
cmd/launch_provider_instance.go:34:2: don't use ALL_CAPS in Go names; use CamelCase
cmd/launch_provider_instance.go:35:2: don't use ALL_CAPS in Go names; use CamelCase
cmd/launch_provider_instance.go:36:2: don't use ALL_CAPS in Go names; use CamelCase
cmd/launch_provider_instance.go:37:2: don't use ALL_CAPS in Go names; use CamelCase
cmd/launch_provider_instance.go:38:2: don't use ALL_CAPS in Go names; use CamelCase
cmd/launch_provider_instance.go:39:2: don't use ALL_CAPS in Go names; use CamelCase
cmd/launch_provider_instance.go:40:2: don't use ALL_CAPS in Go names; use CamelCase
cmd/launch_provider_instance.go:241:6: func Foo should be FOO

如果我将VSCode Go Linter设置更改为:

If I change my VSCode Go Linter settings to be this:

{
    ...
    "go.lintTool": "gometalinter",
    "go.lintFlags": [
        "--disable-all",
        "--enable=golint",
        "--exclude=exported (const|type|method|function) [\\w.]+ should have comment (\\(or a comment on this block\\) )?or be unexported",
        "--exclude=don't use ALL_CAPS in Go names; use CamelCase",
        "--exclude=(func|const|struct field|) \\w+ should be \\w+"
    ]
}

然后，我之前看到的所有警告都被压制了.要了解有关gometalinter的更多信息，请查看项目的主要GitHub页面.

Then all of the warnings I was seeing earlier are squashed. To read more about gometalinter, check out the main GitHub page of the project.

这篇关于是否可以使用Visual Studio Code的linter忽略特定的警告?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！