Можно ли игнорировать определенные предупреждения с помощью линтера кода Visual Studio? - PullRequest
Новая
       27

Можно ли игнорировать определенные предупреждения с помощью линтера кода Visual Studio?

0 голосов
/ 04 июня 2018

Наша компания задумывается о переходе с Sublime на код Visual Studio.

С SublimeLinter можно использовать операторы ignore_match в файле настроек, чтобы игнорировать конкретные предупреждения.Это позволяет нам скрывать ложные срабатывания, такие как отслеживание тегов в URL.

Я пытался найти эквивалентную функцию в VSC, но безрезультатно.Может кто-нибудь сказать мне, если это может быть достигнуто?

Спасибо

1 Ответ

0 голосов
/ 01 ноября 2018

Я думаю, что конфигурация вашего линтера будет зависеть от языка - это ответ для Golang, и, вероятно, он будет сильно отличаться в зависимости от используемого вами языка.

Работа с Golangв VSCode вы можете установить используемый линтер.Есть несколько вариантов, в том числе (по состоянию на 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, посетите главную страницу проекта GitHub .

...