Is it possible to ignore specific warnings with Visual Studio Code's linter?

问题

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

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.

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

Thanks

回答1:

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.

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.

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

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+"
    ]
}

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.

来源：https://stackoverflow.com/questions/50678503/is-it-possible-to-ignore-specific-warnings-with-visual-studio-codes-linter

标签

visual-studio-code

linter