Just as do many others, I have my own coding profile. The overriding approach is to balance the need for white space with the need for vertical compactness. Code must be understood both by others and by some future version of yourself as you make enxancements and fix bugs. Code stretched out to a thin stream of characters down the middle of the page is not readable.

Braces - A left brace does not get a line of its own. Only comments may follow it on a line, unless the contents and right brace can follow the left brace. It is a good idea the the predicate in an if statement always be followed by a left brace, but this I avoid when the contents of the braces are a single short statement.

! in predicates - surrounded by spaces.

when a statement exceeds a line, the break is made before an operator. The the continuation line looks less like a statement on its own.

Assignment operators are surrounded by spaces. But when part of a predicate, the spaces are omitted and the whole assignment is placed in parentheses.

Additive operators are surrounded by spaces; although they are ugly in concatenations.

Many many lines intercede between left and right braces, the right is followed by a comment describing the left.  // end class Foo // method goo, ....

Asterisk in import lines is used sparinngly; only for java.awt.*, java.io.*, javax.swing.*, and java.util.*.

Switch statements with short statements for each case are better with each case on a single line.

Global variables have longer, more meaningful names.

I prefer to avoid recomputation, so I create a varible, assign to it, and use it thereafter. Tthis satisfies my need for optimization (and lack of trust in compiler optimization), but it also increases the degree of indirection, a potential hazard to readability.