Less indentation for switch expression in assignment/initializer
还没有人认领这个 Issue。
评估
调研方向
先定位 formatter 逻辑以及 switch expressions 的现有测试,然后将此 issue 中当前的赋值示例和提议的赋值示例与 return-switch 的格式化进行比较。完成标准是:赋值和变量声明中紧接在右侧的 switch expressions 使用提议的缩进,同时不改变更深层嵌套的情况,并为这些示例提供回归覆盖。
由索引模型根据 Issue 内容生成。
描述
I would like to suggest a different formatting of switch expressions that are used as right-hand side of an assignment: move the switch on the same line as the assignment and reduce indentation, in the same way as is done for switch expressions after a return. I am aware that this deviates slightly from the basic rules of Google Java Format, but I think this case is worth an exception.
Example code with current formatting:
int returnSwitchExpression(int i) {
return switch (i) {
case 0 -> 1;
case 1 -> 2;
default -> 3;
};
}
int assignSwitchExpression(int i) {
int result =
switch (i) {
case 0 -> 1;
case 1 -> 2;
default -> 3;
};
return result;
}
int switchStatement(int i) {
switch (i) {
case 0 -> {
return 1;
}
case 1 -> {
return 2;
}
default -> {
return 3;
}
}
}
Proposed formatting:
int assignSwitchExpression(int i) {
int result = switch (i) {
case 0 -> 1;
case 1 -> 2;
default -> 3;
};
return result;
}
Note how the indentation of the switch cases in the assignment is currently different from both the return switch and the switch statement cases. Conceptually and syntactically the switch assignment is quite similar to the return switch, though, and it would make sense to let it look similarly. If the current formatting of the return switch case is considered fine, then certainly the proposed formatting should be similarly ok for readability and clarity of the code.
A concrete advantage of changing the formatting is that refactorings introduce less diff noise: both the a refactoring from a switch statement to a switch expression in an assigment as well as the refactoring of a switch expression out of a return into an assignment would keep the same indentation. Right now such refactorings necessarily change the indentation and typically lead to the complete switch being shown as changed in a diff. Note that for example Google Error Prone by default warns about such potential refactorings of switch statements into switch expressions, and Eclipse has a similar refactoring, so these are not that rare.
To be clear: I am not arguing for changing any formatting related to switch expressions in different places or those that are nested more deeply in an expression, my proposal is only about the case where the switch expression is the immediate right-hand-side child node of an assignment or variable declaration.
I also do not think that this would lead to problematic inconsistencies between switch expressions in assignments and initializers and those used elsewhere, because I would assume that switch expressions are almost exclusively used in the places discussed here and almost never nested more deeply. For example, the automated refactorings by Google Error Prone only introduce such basic cases and not deeper nestings.
Switch expressions are also syntactically special anyway compared to other expressions (e.g. because they always enforce some line breaks in the expression), so some inconsistency with regards to other expressions could be accepted.
So in summary I would think introducing this special case has a concrete benefit, no readability disadvantage, and does not introduce relevant inconsistencies.
- 主要语言
- Java
- 星标
- 6.2k
- 派生
- 936
- 平均合并
- 6 分钟
- 30 天内合并 PR
- 3
贡献指南
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
google/google-java-format 的其他 Issue
-
难度 2/5 1-3 小时 新手友好度 72/100
google/google-java-format#1094 · 1 条评论 ·
-
难度 5/5 一周以上 新手友好度 15/100
google/google-java-format#1450 · 1 个 reaction ·
-
难度 4/5 3-5 天 新手友好度 55/100
google/google-java-format#1439 · 1 条评论 ·
-
难度 3/5 1-2 天 新手友好度 62/100
google/google-java-format#1436 · 2 条评论 ·
-
难度 3/5 1-2 天 新手友好度 48/100
google/google-java-format#1428 · 3 条评论 ·
查看 google/google-java-format 的全部 Issue
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 75/100
elastic/gradle-plugins#157 ·
-
enhancement Tools
难度 1/5 1 小时以内 新手友好度 75/100
-
难度 2/5 1-3 小时 新手友好度 70/100
apache/rocketmq-dashboard#5008 ·
-
bug
难度 2/5 1-3 小时 新手友好度 75/100
-
DETECT_PARAMETER_NAMES=false silently disables @ConstructorProperties-based Creator detection too 未关闭
难度 2/5 1-3 小时 新手友好度 70/100
FasterXML/jackson-databind#6229 ·