Feature request: Mark specific lines or blocks to ignore for specific rules

Like pragma in c# can disable a warning for a line and then enable it again.

As an example, I've got a few variables that are used to within Invoke-Expression's, and the script analyzer flags them as unused variables but they are actually used. I dont want to ignore the rule for the entire script, just these few variables.

Is there a way to do this?

Andrew Stanton (@StingyJack)

Andrew Stanton (@StingyJack) You could define a local function and suppress it on this local one only (you can define even define functions inside functions to limit its scope).
Because of the way scoping works in PowerShell (a child scope inherits the variables from its parent), you do not even need to pass in the variables in theory (although personally I am against this practice for the purpose of clean code).

something like?

#PSSCRIPTANALYZER -PSAvoidUsingCmdletAliases
gci
#PSSCRIPTANALYZER +PSAvoidUsingCmdletAliases

or something more?

James Truher (@JamesWTruher)

James Truher (@JamesWTruher) Is this a future design proposal because I tried it and it did not work. If so, then yes, I would upvote this. As a simple starter I would suggest something that can just suppress a warning on the next executing line similar to ReSharper

#PSSCRIPTANALYZER SuppressOnce PSAvoidUsingCmdletAliases
gci # gets suppressed
iex 'format c' # does not get suppressed

It's definitely not present, I was just exploring the usability of the suggestion. I do think it would be generally useful and something that would benefit from some sort of RFC. I would like to spark the discussion, for sure.

James Truher (@JamesWTruher)

James Truher (@JamesWTruher) yes, something like that

You should be able to do it with something like

[System.Diagnostics.CodeAnalysis.SuppressMessageAttribute("PSAvoidUsingCmdletAliases", "")]

I just posted an issue where this works for suppressing the error from a single variable (PSUseDeclaredVarsMoreThanAssignments), but it doesn't seem to honor the scope flag (unless I am doing something wrong).

Graham

I'd like to upvote this - I'd like to see a solution that lets me suppress any of the checks for a section of the code in a file, where a section could be a single line, a couple of lines, or the whole file (I have a couple of ps1 files that purely define variables for our environment, so I get hundreds of variable assigned but never used messages.

Graham

James Truher (@JamesWTruher)

Does this need an RFC as James Truher (@JamesWTruher) sort-of suggested?

@swngdnz An RFC might help to push it further and alert about its importance. The only downside is that we could end up creating the most beautiful design that is very hard to implement. We should rather strive to go for a minimum viable improvement to suppress e.g. only the next line/statement. So, yes to being loud, I only fear that RFCs sometimes lead to something being discussed to death. At the end of the day we also need a commitment from someone to implement the proposal, otherwise the RFC is pointless.

Wirth taught me 35 years ago that "best" was the death of progress. That's why he kept designing new languages. :-)

That's why I suggested what I thought would be simple (#pragma once/disable/restore). It's similar to what I did in a C compiler I wrote in the 1980's (although I think I used once/push/pop since it was a stack based compiler).

I'll take a look at it. But I'm not sure my C# skills are good enough (I'm guessing it's C#, if it's javascript, I'm completely out of it).

it's C#. Familiarity with the AST (abstract syntax tree) of PowerShell or at least its tokens are essential but I am happy to help with some bits or gluing stuff together at the end.

Late to the party, but I like it too, even though I have no idea if it would ever be worth the effort for you folks to code it.

BTW, I suppress the specific PSUseDeclaredVarsMoreThanAssignments by assigning variables like this to $null. (I have a few legitimate cases where this is intentional, but don't want to suppress the rule since it is frequently a misspelling or logic error.

I don't want it to vomit an invalid lint to the following code to keep the compatibility between 5- and 6:

if (-not (Test-Path variable:IsWindows)) {
  $IsWindows = Test-Path $env:windir
}

I'm running into something similar as tats-u. I am getting warnings for Get-CimInstance and Get-WmiObject and would like to suppress them given that I have properly limited the code execution so that they are never run in an incompatible environment.

function Get-OperatingSystemVersion
{
    if (Test-OperatingSystemIsWindows)
    {
        if ((Get-PSMajorVersion) -ge 3)
        {
            # Use Get-CimInstance
            $arrCimInstances = @(Get-CimInstance "Win32_OperatingSystem" -ErrorAction SilentlyContinue)
        } `
        else `
        {
            # Use Get-WmiObject
            $arrCimInstances = @(Get-WmiObject "Win32_OperatingSystem" -ErrorAction SilentlyContinue)
        }
        # ....
}

I would like to be able to use a comment to block certain rules on certain lines/blocks of code. I would greatly prefer not to use the param block for this functionality, as not all my code uses a param block. Also the param block would block the rule for the whole function/code scope, which is not desirable.

Frank Lesniak (@franklesniak)

Frank Lesniak (@franklesniak) The rule says that starting from PowerShell v3, the CIM cmdlets should be preferred, so not sure why you cannot use them.
If for whatever reason you want to keep using WMI, you could suppress as follows (see here):

function Get-OperatingSystemVersion
{
    [Diagnostics.CodeAnalysis.SuppressMessageAttribute('PSAvoidUsingWMICmdlet', '', Justification = 'Required for PS 3')]
    Param()

    if (Test-OperatingSystemIsWindows)
    {
        if ((Get-PSMajorVersion) -ge 3)
        {
            # Use Get-CimInstance
            $arrCimInstances = @(Get-CimInstance "Win32_OperatingSystem" -ErrorAction SilentlyContinue)
        } `
            else `

        {
            # Use Get-WmiObject
            $arrCimInstances = @(Get-WmiObject "Win32_OperatingSystem" -ErrorAction SilentlyContinue)
        }
        # ....
    }
}

I'd like to add my vote to this issue. There are definitely use cases where a variable will trigger the "assigned but never used" problem when that's not the case.

I would suggest using a similar functionality to that of DevSkim, which allows for a small comment on the line throwing the error to function as a switch to stop the error. adding '#DevSkim: ignore DS104456' to the end of a line that triggers a warning for using a restricted cmdlet, makes the scanner ignore that specific instance of the violation.

The current situation is indeed ugly. In order to suppress the relevant warning for a few lines - and only a few lines - of a script, I have to do something with this form:


[Diagnostics.CodeAnalysis.SuppressMessageAttribute('PSUserDeclaredVarsMoreThanAssignments', '', scope='function')]
$LogEngineHealthEvent					=   $false
[Diagnostics.CodeAnalysis.SuppressMessageAttribute('PSUserDeclaredVarsMoreThanAssignments', '', scope='function')]
$LogEngineLifeCycleEvent				=   $false
[Diagnostics.CodeAnalysis.SuppressMessageAttribute('PSUserDeclaredVarsMoreThanAssignments', '', scope='function')]
$LogProviderHealthEvent					=   $false
[Diagnostics.CodeAnalysis.SuppressMessageAttribute('PSUserDeclaredVarsMoreThanAssignments', '', scope='function')]
$LogProviderLifeCycleEvent				=   $false

I tried using

param(
    [Parameter(Mandatory = $true)]
    [Alias('MP')]
    [String]
    [System.Diagnostics.CodeAnalysis.SuppressMessageAttribute('PSReviewUnusedParameter', '', scope = 'function')]
    $MyParameter
)

but it doesn't work.

UPVOTE!!!

We have a tool that runs PSScriptAnalyzer as part of our Pull Request process. It will not let anything be checked in that has any Errors or Warnings.
Recently, we started seeing a lot of PSUseSingularNouns. In some cases this is intentional. For example: Send-MessageToTeams (As in Microsoft Teams)

We have had to disable that rule so we can keep things the way we want them, but it would be FAR better to be able to disable the rule just in the approved cases.

Making a note here in case someone else runs into this issue. I noticed that you cannot place the SuppressMessageAttribute on specific parameters in a Param block, but instead you have to place the attribute on the Param block as a whole.

function Verb-PrefixNoun {
    [CmdletBinding()]
    [Diagnostics.CodeAnalysis.SuppressMessageAttribute('PSAvoidDefaultValueSwitchParameter', '')]
    Param (
        [Parameter(Mandatory)
        [switch] $MyParameter = $true
    )
}

Just ran into this when installing Chocolatey on a clean Windows device for the first time. The Choco docs suggest the use of Invoke-Expression. I'd have liked to suppress the PSAvoidUsingInvokeExpression warning with a comment, but it doesn't seem possible.

Using comments would be nice. Rubocop does something like:

# rubocop:disable RuleByName
This is a long line 
# rubocop:enable RuleByName

It also supports having multiple rules disabled with a simple string array.

Gilbert Sanchez (@HeyItsGilbert)

Comments should be the way to go IMHO, you do not want to interfere with the script logic itself. eslint also uses the same approach as Gilbert Sanchez (@HeyItsGilbert) mentioned. It also has an disable-next-line comment. Which comes in very handy, so you almost never have to use block with enable and disable, just sometimes.

As a previous commenter wrote: "Just ran into this when installing Chocolatey on a clean Windows device for the first time."
This github issue seems like one of many examples where linux-based tools do things in a simple, obvious, easy way (at least to me) while windows or powershell are convoluted and confusing. On all linters that I have seen before, you can "mark specific lines or blocks to ignore for specific rules."

I appreciate the ongoing discussion for this issue. I wanted to add my experience since the last update was over a year ago. I just spent a non-trivial amount of time trying to figure out how to suppress a rule one time with a comment.

Comment-based directives for linting are widely supported across languages and tools. I'm sure it's not something that's easy to just implement, however, so please don't take this comment as criticism of the timeline.

Here are some examples for what I mean by widely supported:

JavaScript / TypeScript (ESLint) -> // eslint-disable-next-line no-console
Python (pylint) -> # pylint: disable=unused-variable
Python (flake8) -> # noqa: E501
Go (staticcheck) -> //lint:ignore ST1006 using unconventional receiver name
Rust (Clippy) -> #[allow(clippy::unwrap_used)]
C# (Roslyn analyzers) -> #pragma warning disable IDE0051
Java (Checkstyle) -> @SuppressWarnings("checkstyle:MagicNumber")
C / C++ (clang / gcc) -> #pragma GCC diagnostic ignored "-Wunused-variable"
Ruby (RuboCop) -> # rubocop:disable Metrics/AbcSize
Bash / Shell (ShellCheck) -> # shellcheck disable=SC2086
Ansible YAML (ansible-lint) -> # noqa: git-latest partial-become
Terraform (tflint) -> # tflint-ignore: aws_instance_invalid_type

Apologies if any of those examples are flawed. I had an AI assist me in creating the initial list and I checked/revised it best I could.

Thanks for keeping this discussion going. I wish I had the expertise to help out.

Navigation Menu

Repository navigation

Feature request: Mark specific lines or blocks to ignore for specific rules #849

UPVOTE!!!

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Feature request: Mark specific lines or blocks to ignore for specific rules #849

Description

Activity

bergmeister commented on Jan 21, 2018

JamesWTruher commented on Jan 22, 2018

bergmeister commented on Jan 22, 2018

JamesWTruher commented on Jan 22, 2018

StingyJack commented on Jan 23, 2018

gmitch64 commented on Feb 6, 2018

gmitch64 commented on Feb 12, 2018

essentialexch commented on Nov 21, 2018

bergmeister commented on Nov 21, 2018

essentialexch commented on Nov 21, 2018

bergmeister commented on Nov 21, 2018

HerbM commented on Oct 6, 2019

tats-u commented on Dec 23, 2019

franklesniak commented on Jan 6, 2020

bergmeister commented on Jan 6, 2020

Royalty087 commented on Apr 9, 2020

LinuxOnTheDesktop commented on May 27, 2021

revolter commented on May 30, 2021

VWACRansom commented on Sep 30, 2021

UPVOTE!!!

srbrills commented on Nov 7, 2023

syedhassaanahmed commented on Feb 15, 2024

HeyItsGilbert commented on Apr 11, 2024

air2 commented on Apr 25, 2024

sdarwin commented on Aug 23, 2024

neodon commented on Oct 14, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions