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
When formatting code to meet the AOSP style, the indention applied to code blocks with many continuations can make the code difficult to read. Here is an example inspired by code I have worked with:
There are a few elements of this formatting which makes the code difficult to read:
The argument list for the lambda is on a separate line than the function to which it is passed. This makes it difficult to determine how the lambda is used. This issue is already described in Issue 19 odd formatting for lambdas.
The storageService variable is indented five spaces beyond the opening parenthesis of the argument list it is a part of. This makes it difficult to recognize that the storageService variable is the start of the expression which is passed to assertThat().
The isTrue() call is indented 27 spaces less than the expression on which it is invoked, and more jarringly, ends 6 spaces before the start of the previous line. This makes it difficult to determine the expression on which isTrue() is invoked. While in this specific instance the use of isTrue() could be avoided entirely by calling IterableSubject::isEmpty, it serves to illustrate the point at hand.
Taken as a whole, this code is difficult to read because the indentation used leads to closely-related segments of code being separated by lots of whitespace. This obfuscates the relationships between these code segments.
Proposed solution
A reasonable solution to this problem is to use two-space continuations rather than eight-space continuations when formatting code in the AOSP style. Before detailing the arguments in favor of this approach, I first present the above code, reformatted to use two-space continuations:
This does not solve the first problem listed above, but it does help with the other two. storageService is now quickly identifiable as the start of the expression passed to assertThat(), and while isTrue() still has slightly confusing indentation, it is no longer completely separated by whitespace from the expression it is invoked on.
I now turn to the general arguments for this solution.
Arguments for proposal
The first argument in favor of this proposal is that using two-space tabs for continuations reduces the overall number of continuations. This is because the second half of the continuation can be an additional six characters long before hitting the line length limit, reducing the likelihood that a second continuation will be required. Notice how isEmpty() is on its own line in the first code snippet, but is not in the second.
The second argument in favor of this proposal is that two-space continuations are just as effective as eight-space continuations. The purpose of using a separate tab width for a continuation is to indicate to the reader that the second half of the continuation is not the start of a new statement, but is, in fact, a continuation. It is not necessary to double the width of a standard tab to accomplish this. Rather, the tab width for a continuation must merely be different than the standard tab width; in this case, continuations must not be four spaces wide.
There is precedent for using a continuation tab width half that of that used for standard tabs. The C Style and Coding Standards for SunOS from Sun mandates exactly this. Section 13, Continuation Lines, specifies that a continuation "should be further indented by half a tab stop" than the above line. Given that the standard width of a tab stop in the SunOS source code is 8 spaces, it is easy to see why halving, rather than doubling, this width was desirable for continuation tabs. Given the extent to which expressions can be deeply nested in modern Java, the same can be said for continuations in the AOSP style.
The text was updated successfully, but these errors were encountered:
The AOSP style guide currently requires 8 space indents for continuation lines. google-java-format follows the existing style rules, this isn't the right place to propose style guide changes.
Hi Cushon,
Thanks for your response. As a clarification, I should note that I was requesting that google-java-format add an additional formatting option, not that the AOSP style guide be modified. Effectively, I'm requesting an option to format code in what is almost the AOSP style, with the one difference being that 2 space indents for continuations are used rather than 8 space indents.
Looking at the title of my issue, I see why this might not have been clear, and I apologize for any confusion. I realize that this request might still be rejected, but I want to make sure the issue is not closed due to a misunderstanding.
Problem
When formatting code to meet the AOSP style, the indention applied to code blocks with many continuations can make the code difficult to read. Here is an example inspired by code I have worked with:
There are a few elements of this formatting which makes the code difficult to read:
storageService
variable is indented five spaces beyond the opening parenthesis of the argument list it is a part of. This makes it difficult to recognize that thestorageService
variable is the start of the expression which is passed toassertThat()
.isTrue()
call is indented 27 spaces less than the expression on which it is invoked, and more jarringly, ends 6 spaces before the start of the previous line. This makes it difficult to determine the expression on whichisTrue()
is invoked. While in this specific instance the use ofisTrue()
could be avoided entirely by callingIterableSubject::isEmpty
, it serves to illustrate the point at hand.Taken as a whole, this code is difficult to read because the indentation used leads to closely-related segments of code being separated by lots of whitespace. This obfuscates the relationships between these code segments.
Proposed solution
A reasonable solution to this problem is to use two-space continuations rather than eight-space continuations when formatting code in the AOSP style. Before detailing the arguments in favor of this approach, I first present the above code, reformatted to use two-space continuations:
This does not solve the first problem listed above, but it does help with the other two.
storageService
is now quickly identifiable as the start of the expression passed toassertThat()
, and whileisTrue()
still has slightly confusing indentation, it is no longer completely separated by whitespace from the expression it is invoked on.I now turn to the general arguments for this solution.
Arguments for proposal
The first argument in favor of this proposal is that using two-space tabs for continuations reduces the overall number of continuations. This is because the second half of the continuation can be an additional six characters long before hitting the line length limit, reducing the likelihood that a second continuation will be required. Notice how
isEmpty()
is on its own line in the first code snippet, but is not in the second.The second argument in favor of this proposal is that two-space continuations are just as effective as eight-space continuations. The purpose of using a separate tab width for a continuation is to indicate to the reader that the second half of the continuation is not the start of a new statement, but is, in fact, a continuation. It is not necessary to double the width of a standard tab to accomplish this. Rather, the tab width for a continuation must merely be different than the standard tab width; in this case, continuations must not be four spaces wide.
There is precedent for using a continuation tab width half that of that used for standard tabs. The C Style and Coding Standards for SunOS from Sun mandates exactly this. Section 13, Continuation Lines, specifies that a continuation "should be further indented by half a tab stop" than the above line. Given that the standard width of a tab stop in the SunOS source code is 8 spaces, it is easy to see why halving, rather than doubling, this width was desirable for continuation tabs. Given the extent to which expressions can be deeply nested in modern Java, the same can be said for continuations in the AOSP style.
The text was updated successfully, but these errors were encountered: