是否可以使用 Visual Studio Code 的 linter 忽略特定警告？

Posted 2023-03-22

【中文标题】是否可以使用 Visual Studio Code 的 linter 忽略特定警告？

【英文标题】：Is it possible to ignore specific warnings with Visual Studio Code's linter?

【发布时间】：2018-11-13 15:59:33

【问题描述】：

我们公司正在考虑从 Sublime 切换到 Visual Studio Code。

使用 SublimeLinter，可以在首选项文件中使用 ignore_match 语句来忽略特定警告。这让我们可以隐藏 URL 中的跟踪标签等误报。

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

谢谢

【问题讨论】：

为什么要忽略警告？他们在那里是有原因的。

我们将使用它来开发电子邮件，因此有很多骇人听闻的代码和标记为警告的跟踪标签。隐藏这些可以让我们更有效地扫描需要注意的错误。

Linters 是特定于语言的（通常由第三方工具提供）。您可能必须根据具体情况对其进行分析。你说的是 html 吗？

HTML 和 CSS。用户偏好允许对 linter 进行一些控制，但只能从非常广泛的层面进行 - 例如。隐藏所有未知属性。这符合我们想要完成的目标，但我们只想隐藏特定属性。

【参考方案1】：

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

在 VSCode 中使用 Golang，您可以设置您使用的 linter。有多种选择，包括（截至 2018 年 10 月 31 日）gometalinter。 gometalinter 提供了--exclude 标志，可用于忽略特定的警告文本。

例如，我当前的项目有来自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 设置更改为：

    ...
    "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 的更多信息，请查看the main GitHub page of the project。

【讨论】：

python有办法吗？

我认为这取决于您正在使用的特定 linter 以及此类事情在 VSCode 中是如何出现的。查看 PyLint 文档 (pylint.pycqa.org/en/latest/user_guide/message-control.html) 上的消息控制页面，并阅读 VS Code 中的插件文档。希望这可以帮助。 :)

【参考方案2】：

这对我有用 -

//nolint:gosec

【参考方案3】：

您可以为此使用模块：

import warnings
warnings.filterwarnings( 'ignore' )