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

[Igor Ignatyev]

On Tue, 20 Oct 2020 01:13:33 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> 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.

Although I don't think that the test code has the same frequency of changes as the product code, I'd still prefer
consistency and maintainability over some small penalty (which is IMHO negligible) in readability.

frankly, it's also partially motivated by my laziness as I don't want to go over all these files again and examine each
and every initialization for possible (scanty) readability improvements from horizontal alignment.

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

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