RFR: 8254861: reformat code in vmTestbase/nsk/jdb [v2]

[Chris Plummer]

On Tue, 20 Oct 2020 00:04:16 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> test/hotspot/jtreg/vmTestbase/nsk/jdb/caught_exception/caught_exception002/caught_exception002.java line 87:
>> 
>>> 85:     static final String DEBUGGEE_CLASS = TEST_CLASS + "a";
>>> 86:     static final String FIRST_BREAK = DEBUGGEE_CLASS + ".main";
>>> 87:     static final String LAST_BREAK = DEBUGGEE_CLASS + ".lastBreak";
>> 
>> I'm not so sure I'd consider this change an improvement. Maybe remove some of the extra spaces but keep the alignment.
>
> although horizontal alignment (of variable names, initialization, expressions, etc) seems to somewhat improve
> readability, it almost always associated with a higher maintenance cost, and the current consensus is not to do that.
> from 'Horizontal Whitespace' section of the same
> [guidelines](http://cr.openjdk.java.net/~alundblad/styleguide/index-v6.html#toc-whitespace):
>> In variable declarations it is not recommended to align types and variables.
> *Motivation*
> The improvement in readability when aligning variable names is negligible compared to the efforts needed to keep them
> aligned as the code evolves. Realigning all variables when one of the types change also causes unnecessarily
> complicated patches to review.  other java code guidelines either discourage horizontal alignment or consider it
> optional and provide the same motivation as above to why it's better not to have it.

While in general I agree that gratuitous aligning of variables is not desirable, this is a special case where it adds
value (enough that I think it's worth doing). The value here is due to the fact that the variables are building on each
other. When they are aligned it's easier to scan for the variable (and its value) that another variable builds on.

You can keep your change in place if you feel that consistency and maintainabilty is more important here than
readability.

-------------

PR: https://git.openjdk.java.net/jdk/pull/689