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
With IgnoreOneLineBlock = $false, splitting a one-line if/else produced stray leading and trailing spaces, a } indented by 3 spaces, and a else with a leading space:
About the issue's expected output: these settings run only the two brace rules. PSPlaceCloseBrace.NewLineAfter defaults to $true, so it puts else on its own line, and none of the enabled rules indents the body (that's PSUseConsistentIndentation). The "After" column is therefore the correct result. The CodeFormattingOTBS preset with IgnoreOneLineBlock = $false now produces exactly the output the issue expected:
if ($RegEx) {
'-match'
} else {
'-like'
}
Changes
PlaceOpenBrace, NewLineAfter correction: the correction extent now runs from { to the next token on the same line, so it also removes the whitespace after the brace.
PlaceCloseBrace, BraceShouldBeOnNewLine correction: when the preceding token is on the same line, the extent now starts at that token's end, so it also removes the whitespace before }.
PlaceCloseBrace.GetIndentation: the loop condition was k > 0, so it never checked the first token in the script. When the open brace was on the first line, } took its indentation from the 2nd token (( → 3 spaces). Changed to k >= 0. This also affects the NoEmptyLineBefore correction, which uses the same helper.
PlaceCloseBrace, NewLineAfter correction: the extent now runs from } up to the branch keyword (else/elseif/catch/finally). The replacement is } + newline + the brace's indentation, so the keyword lines up with } and no leading space remains.
Tests
Three existing correction-extent tests now expect ViolationText to be '} ' (brace plus the following space) because the extent now includes that space.
Added regression tests:
the scenario from the issue;
a nested block, to check that } and else keep their indentation;
…ce and wrong indentation
Co-authored-by: bergmeister <9250262+bergmeister@users.noreply.github.com>
CopilotAI
changed the title
[WIP] Fix IgnoreOneLineBlock=false correction issue in PSPlaceOpenBrace and PSPlaceCloseBrace
Fix PlaceOpenBrace/PlaceCloseBrace corrections leaving stray whitespace and misindented braces
Oct 27, 2026
The reason will be displayed to describe this comment to others. Learn more.
🟡 Changes recommended
The correction can misalign else after a multiline condition by using the opening-brace line’s indentation instead of preserving the closing brace’s leading whitespace, and regression coverage is needed.
This PR addresses #2218 by refining brace-formatting corrections so splitting one-line blocks removes stray whitespace and aligns closing braces and branch keywords.
Changes:
Extend correction ranges to consume whitespace adjacent to braces.
Include the script’s first token when calculating closing-brace indentation.
Add regression tests for one-line statements, nested branches, OTBS formatting, and correction ranges.
File
Description
Tests/Rules/PlaceOpenBrace.tests.ps1
Verify that opening-brace corrections consume following whitespace.
Tests/Rules/PlaceCloseBrace.tests.ps1
Update correction expectations and add formatting regressions.
Rules/PlaceOpenBrace.cs
Remove whitespace after { when inserting a newline.
Rules/PlaceCloseBrace.cs
Adjust correction ranges and indentation for closing braces and branches.
The reason will be displayed to describe this comment to others. Learn more.
🔵 Needs a closer look
The formatter uses continuation-line indentation for multiline conditions, causing correctly aligned } else { blocks to gain an extra-indented else that brace-only formatting does not repair.
Use closing brace indentation for split-condition else formatting
Rules/PlaceCloseBrace.cs:288
For a condition split as if ($a -and followed by an indented $b) {, GetIndentation() returns the continuation line's indentation rather than the closing brace's indentation. An already correctly aligned } else { therefore becomes } followed by an extra-indented else, which brace-only formatting does not repair. Use the closing brace's actual leading whitespace when it already starts its own line, falling back to the helper only for an inline brace.
The reason will be displayed to describe this comment to others. Learn more.
🟡 Changes recommended
The closing-brace rule replaces tab-based indentation with spaces when splitting a branch, misaligning else; it needs to preserve the original leading whitespace and include a tab-indented regression test.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
With
IgnoreOneLineBlock = $false, splitting a one-lineif/elseproduced stray leading and trailing spaces, a}indented by 3 spaces, and aelsewith a leading space:if ($RegEx) {'-match'
}
else {
'-like'
}
if ($RegEx) {'-match'
}
else {
'-like'
}
About the issue's expected output: these settings run only the two brace rules.
PSPlaceCloseBrace.NewLineAfterdefaults to$true, so it putselseon its own line, and none of the enabled rules indents the body (that'sPSUseConsistentIndentation). The "After" column is therefore the correct result. TheCodeFormattingOTBSpreset withIgnoreOneLineBlock = $falsenow produces exactly the output the issue expected:Changes
PlaceOpenBrace, NewLineAfter correction: the correction extent now runs from{to the next token on the same line, so it also removes the whitespace after the brace.PlaceCloseBrace, BraceShouldBeOnNewLine correction: when the preceding token is on the same line, the extent now starts at that token's end, so it also removes the whitespace before}.PlaceCloseBrace.GetIndentation: the loop condition wask > 0, so it never checked the first token in the script. When the open brace was on the first line,}took its indentation from the 2nd token ((→ 3 spaces). Changed tok >= 0. This also affects theNoEmptyLineBeforecorrection, which uses the same helper.PlaceCloseBrace, NewLineAfter correction: the extent now runs from}up to the branch keyword (else/elseif/catch/finally). The replacement is}+ newline + the brace's indentation, so the keyword lines up with}and no leading space remains.Tests
ViolationTextto be'} '(brace plus the following space) because the extent now includes that space.}andelsekeep their indentation;IgnoreOneLineBlock = $false;