Format guard clauses in switches. #1383
Merged
Conversation
This file contains 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
There were enough tweaks in the formatting specific to the two contexts where the guards can appear that I ultimately decided to make new Piece classes for switch expression cases and switch statement cases. I was hoping for more code reuse, but I think it would have been harder to maintain if I jammed all of this into a single Piece class. I also slightly tweaked the indentation style of switch expression cases. When I'd first added support for switch expressions in the new formatter, I changed the style from what the old formatter had, for reasons that aren't entirely clear. Maybe I thought it made it more consistent to indent +4? Either way, once guard clauses came into play, it became clear that the old style made more sense because it gives a clearer indentation level for the `when` clause when it splits. So this change also makes switch expression formatting more similar to the old style.
munificent
commented
Feb 14, 2024
| @@ -28,7 +28,7 @@ e = switch (c) { | |||
| e = switch (c) { | |||
| first => a, | |||
| second => | |||
| veryLongExpression + thatSplits, | |||
| veryLongExpression + thatSplits, | |||
There was a problem hiding this comment.
This is the style change. By indenting bodies +2 instead of +4, it makes it more natural to indent the when clause +4 when it splits. If we indent the body +4, then you have to do like +8 for the when clause which looks pretty extreme.
natebosch
approved these changes
Feb 14, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
There were enough tweaks in the formatting specific to the two contexts where the guards can appear that I ultimately decided to make new Piece classes for switch expression cases and switch statement cases. I was hoping for more code reuse, but I think it would have been harder to maintain if I jammed all of this into a single Piece class.
I also slightly tweaked the indentation style of switch expression cases. When I'd first added support for switch expressions in the new formatter, I changed the style from what the old formatter had, for reasons that aren't entirely clear. Maybe I thought it made it more consistent to indent +4?
Either way, once guard clauses came into play, it became clear that the old style made more sense because it gives a clearer indentation level for the
whenclause when it splits. So this change also makes switch expression formatting more similar to the old style.