In the interest of readability:
I'm afraid that the original not only is likely not to fit on smaller displays, but also our formatter tend to obscure critical text.
Note that if you use an
IDE's automated pretty-printer, some (depending on settings) may put the "." operators at the end of the line, not the beginning, but I find the operator-at-the-beginning more informative to me.
As for general nit-picking, I'm certainly one for complex statements, but this is a bit much. Also, there are two reasons why breaking this up into simpler statements is a good idea (indentation or not).
First, if you have to step through the code with a debugger, debuggers step per-statement so a LOT of details will be more or less invisible in a complex statement.
Secondly, if you break the code into smaller sequences, it's easier to capture the intermediate values in case you want to print them out to a debug log.
And, if you are REALLY paranoid, you can always put assertions into the code, although I've never seen anyone use the
Java assert the way it is in C/C++. Partly, I think because Java's
assert is overly complex. Instead we prefer unit-test assertion methods.
Last, but not least, as I've mentioned elsewhere, I prefer to document the allowable data values that go into code. We could, based on context, assume that the percentage can be blank or a number from 0 to 100, but maybe you work for a firm that demands 100%. Or gets negative percentages.
The statement also seems to try to sanitize data. I'm not so kind. If they cram in non-numeric characters into a numeric field, I'm going to reject the whole request. Who knows what else they messed up?