Repository navigation
PSUseConsistentWhitespace for Pester tests and 'Should Throw' #1298
Description
Steps to reproduce
Testing.Tests.ps1 contains:
Describe -Name 'Test' -Fixture {
It -Name 'Test' -Test {
{1 / 0} | Should throw
}
}Expected behavior
No PSScriptAnalyzer issues.
Actual behavior
PSScriptAnalyzer requires a space before the opening brace. The indentation puts eight spaces before the brace. Maybe it's to do with the fact that there is nothing before the opening brace. However, this is the recommended way of testing for exceptions in Pester.
{
"resource": "/<REMOVED>/Testing.Tests.ps1",
"owner": "_generated_diagnostic_collection_name_#0",
"code": "PSUseConsistentWhitespace",
"severity": 4,
"message": "Use space before open brace.",
"source": "PSScriptAnalyzer",
"startLineNumber": 5,
"startColumn": 9,
"endLineNumber": 5,
"endColumn": 10
}Environment data
VS Code
Version: 1.36.1 (user setup)
Commit: 2213894ea0415ee8c85c5eea0d0ff81ecc191529
Date: 2019-07-08T22:59:35.033Z
Electron: 4.2.5
Chrome: 69.0.3497.128
Node.js: 10.11.0
V8: 6.9.427.31-electron.0
OS: Windows_NT x64 10.0.18362Installed Extensions for VS Code
alefragnani.Bookmarks
Damien.autoit
eamodio.gitlens
ms-vscode.csharp
ms-vscode.powershell
ms-vscode.powershell-preview
streetsidesoftware.code-spell-checker
vscode-icons-team.vscode-icons
> $PSVersionTable
Name Value
---- -----
PSVersion 6.2.2
PSEdition Core
GitCommitId 6.2.2
OS Microsoft Windows 10.0.18362
Platform Win32NT
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0> (Get-Module -ListAvailable PSScriptAnalyzer).Version | ForEach-Object { $_.ToString() }
1.18.1
1.18.0
1.18.0Various Settings Files
settings.json
PSScriptAnalyzerSettings.psd1
CustomRule.psm1
Activity
bergmeister commentedon Jul 28, 2019
Thanks for the report. Some of the formatting rules were written quite simplistically a few years ago, I am aware that there are a few red herring warnings. Most users don't see them because they don't use custom settings or don't use formatting rules as part of the 'analysis' and their nature is usually harmless. But I still think it's good to write them down and tackle them one by one and slowly make the Formatter better because there are still weird edge cases where the Formatter does not format when it should or corrections cancel each other out, etc. and this would be a small but useful start to tackle the bigger problem. :-)
msftrncs commentedon Aug 21, 2019
Is this a case where the error message is just incorrect? Looks like it means 'after brace', as that's what 'format document' will do.
mrboring commentedon Aug 21, 2019
Carl Morris (@msftrncs) Yes, in this context, the error message is incorrect. Putting a space after the opening brace does not resolve the problem. Also, the following code does not have the error:
I believe it's related to the opening brace being the beginning of the command. Normally an opening brace is associated with the preceding code. Hope this makes sense.
msftrncs commentedon Aug 24, 2019
I think the correct way to state the issue is that its related to a 'scriptblock', where the rule is meant for a 'statementblock'. 'scriptblock's are for arguments or operands, and a 'statementblock' is for use after a control keyword.
Technically I think the rule should work regardless of the type of block, but when its a scriptblock it must be confused that there is no keyword before it.
felixfbecker commentedon Nov 20, 2019
I have the same issue :(