The ProvideVerboseMessage rule should be limited to functions that support ShouldProcess

[imfrancisd]

A lot of functions don't need verbose messages, and having them output verbose messages will just create noise.

PowerShell itself has many cmdlets that don't write verbose messages, such as ForEach-Object, Test-Path, Get-ChildItem, etc.

I think that the $VerbosePreference variable will become useless if everyone followed this rule the way it is now because of all the noise that will be generated.

[GoodOlClint]

The functionality used to be all scripts/functions required Write-Verbose. This was changed in #113 to only functions that call the [CmdletBinding()] attribute per community rule OUT-04

[imfrancisd]

The link you provided states:

    Use [CmdletBinding()] if you are using write-debug or write-verbose

but the rule right now is:

    Use Write-Verbose if you have [CmdletBinding()]

Very different results.

[raghushantha]

Francis.

Currently, the rule is "Information" level and applies to functions that have the CmdletBinding() attribute specified to reduce noise. This is a good practice since it gives debug information about the cmdlet actions.

In what scenarios are you seeing a lot of noise?

Thanks,
Raghu

[imfrancisd]

There are a lot of functions that shouldn't have verbose messages (look at the PowerShell cmdlets that don't have verbose messages), but this rule encourages scripters to add them anyway without giving a hint about what to put in those messages.

So, new scripters will probably end up writing messages like:

    write-verbose -message 'my function was called'

or

    write-verbose -message "the value of some local variable that no one cares about is 5"

and so on.

Experienced scripters who do not want verbose messages, but must follow this rule (for whatever reason), will end up with code like this:

    if ($false) {write-verbose -message 'because I have to'}

or

    $VerbosePreference = 'silentlycontinue'
    Write-Verbose -message 'useless message'

and so on.

I think the way this rule is written right now will ultimately do more harm than good.

[imfrancisd]

If the link that @GoodOlClint provided is what this rule is supposed to enforce, then the rule misinterpreted the best practice.

[quoctruong]

This is fixed by #238