Less indentation for switch expression in assignment/initializer
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 42/100
Hướng nghiên cứu
Bắt đầu bằng cách xác định logic của formatter và các bài kiểm thử hiện có cho switch expressions, sau đó so sánh các ví dụ về phép gán hiện tại và được đề xuất trong issue này với cách định dạng return-switch. Công việc được hoàn tất khi các switch expressions nằm ngay ở vế phải trong phép gán và khai báo biến sử dụng cách thụt lề được đề xuất mà không thay đổi các trường hợp lồng nhau sâu hơn, đồng thời có coverage hồi quy cho các ví dụ.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
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.
- Ngôn ngữ chính
- Java
- Star
- 6.2k
- Fork
- 936
- Merge trung bình
- 6 phút
- Pull request đã merge (30 ngày)
- 3
Hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của google/google-java-format
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
google/google-java-format#1094 · 1 bình luận ·
-
Complementary Teamups Đang mở
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 15/100
google/google-java-format#1450 · 1 reaction ·
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 55/100
google/google-java-format#1439 · 1 bình luận ·
-
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 62/100
google/google-java-format#1436 · 2 bình luận ·
-
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 48/100
google/google-java-format#1428 · 3 bình luận ·
Tất cả issue của google/google-java-format
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
elastic/gradle-plugins#157 ·
-
enhancement Tools
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 75/100
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
apache/rocketmq-dashboard#5008 ·
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
-
DETECT_PARAMETER_NAMES=false silently disables @ConstructorProperties-based Creator detection too Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
FasterXML/jackson-databind#6229 ·