Repository navigation
Code Formatting : Whitespacing one line hashtable #1113
Description
Hello
I am looking for a improvment on the current formatting tools by adding a whitespace after open bracket and before closing non empty curly brackets like :
#Actual
$emptyHash = @{ } # an empty Hash
$myHash = @{foo = "bar"}
#Expected
$emptyHash = @{} # an empty Hash
$myHash = @{ foo = "bar" } #whitespace after `{ `and before ` }`
Additional information:
-
I use the PowerShell extension on VS Code to format automaticaly my code on save.
-
My settings.json file:
{
"editor.formatOnSave": true,
"powershell.codeFormatting.preset": "Custom",
"powershell.codeFormatting.alignPropertyValuePairs": true,
"powershell.codeFormatting.ignoreOneLineBlock": false,
"powershell.codeFormatting.newLineAfterCloseBrace": true,
"powershell.codeFormatting.newLineAfterOpenBrace": true,
"powershell.codeFormatting.openBraceOnSameLine": false,
"powershell.codeFormatting.whitespaceAfterSeparator": true,
"powershell.codeFormatting.whitespaceAroundOperator": true,
"powershell.codeFormatting.whitespaceBeforeOpenBrace": true,
"powershell.codeFormatting.whitespaceBeforeOpenParen": true,
"powershell.scriptAnalysis.enable": true,
"files.trimTrailingWhitespace": true,
}This feature exist on other language :
microsoft/TypeScript#9613 (comment)
Regards,
Activity
bergmeister commentedon Dec 19, 2018
Joe-Tux You will be pleased that currently there is already the open PR #1092 that will take care of the whitespace inside curly braces and I'also double checked that it also includes hashtables as well.
msftrncs commentedon May 7, 2019
Christoph Bergmeister (@bergmeister), it seems part of this issue has been addressed, but I am still seeing empty hashtable's being spaced out:
@{}->@{ }.daviesj commentedon Sep 29, 2020
As of version 1.19.1 I am still seeing a problem here but it has changed. Now if you try the same example, this is what you get:
There is now a space added before the right brace but not after the left brace.
I have to say I disagree with the OP though. To me, a hashtable literal seems closer to an array literal than a script block, so if
@(1, 2, 3)is valid formatting then why not@{foo = "bar"}? However, I realize that is a matter of opinion. Either@{foo = "bar"}or@{ foo = "bar" }is better than@{foo = "bar" }which is what you get now.