You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Formatting breaks pattern needed for null-conditonal operators by adding spaces #2066
I've been debugging my script for hours, and finally figured out that the format I did last time, broke my null-conditional operators as it adds spaces between the braces, for example:
$c=$a.{b}?.Trim();
Turns into
$c=$a.{ b }?.Trim();
Causing $c to be empty/null
I fixed this manually in my script but noticed that formatting changes it back - I think this is a wrong format for this specific use-case as it breaks these operators.
It's definitely the CheckInnerBrace part of UseConsistentWhitespace. Turning it on and off for a simple case, $a.{Prop}, confirms it.
The curly-braced member access (not sure on any official naming) isn't parsed into any special AST node structure, and the token stream is just basically VARIABLE, DOT, LCURLY, IDENTIFIER, RCURLY.
Accounting for this would be a case of looking for the braces that are used in this way and ignoring them when it comes time to formatting.
It's made complex by the below being valid:
$a= [PSCustomObject]@{
'Prop'=5'{Prop}'='Value''$a.{Prop}'='Value2-electric-boogaloo'
}
$a.{{Prop}} # prints 'Value'$a.{$a.{Prop}} # prints 'Value2-electric-boogaloo'
So nothing contained within the curly-braced member access braces should be formatted at all as it breaks it.
One strategy could be:
Keep a list of excluded extents/ranges.
Iterate over tokens, for each dot token:
Check the dots extent isn't in an excluded extent/range
Check the dot has a preceding significant token (ignoring comments and skipping on line continuations and new lines) with no whitespace or new-line gaps. Variables, identifiers, literals, braces - all appear to be acceptable.
Check the dot's following significant token (ignoring comments, new lines, line continuations) is a LCURLY.
Find the matching RCURLY for this LCURLY.
Add an extent/range to the ignored list that goes from the LCURLY to the RCURLY.
When considering a brace for a whitespace addition, check first that it's not within an ignored extent/range.
Andy Jordan (@andyleejordan) - Does that sound like a reasonable approach or am I over-complicating it and missing something simpler?
Activity
andyleejordan commentedon Feb 25, 2025
Hi there, this looks to me like a potential bug in PSScriptAnalyzer, specifically the part of the UseConsistentWhitespace rule that looks for spaces within braces: https://github.com/PowerShell/PSScriptAnalyzer/blob/main/docs/Rules/UseConsistentWhitespace.md#checkinnerbrace-bool-default-value-is-true
I'm going to transfer to that repo, it would be helpful if you can confirm by enabling/disabling that rule.
liamjpeters commentedon Nov 3, 2025
It's definitely the
CheckInnerBracepart ofUseConsistentWhitespace. Turning it on and off for a simple case,$a.{Prop}, confirms it.The curly-braced member access (not sure on any official naming) isn't parsed into any special AST node structure, and the token stream is just basically VARIABLE, DOT, LCURLY, IDENTIFIER, RCURLY.
Accounting for this would be a case of looking for the braces that are used in this way and ignoring them when it comes time to formatting.
It's made complex by the below being valid:
So nothing contained within the curly-braced member access braces should be formatted at all as it breaks it.
One strategy could be:
Andy Jordan (@andyleejordan) - Does that sound like a reasonable approach or am I over-complicating it and missing something simpler?