> I tend to agree that the line width spotless uses is too narrow for my taste, > but I guess it is not configurable, and I still prefer some standard over the > mishmash we had before.
It's one of the key reasons I think this is an advantage - you can't have 100 people agree on a consistent format. Not possible. Here you just have to accept the way it's formatted and live with it. Sometimes you can reshape your code to make it more aligned with your expectations though. For example: -········byte[]·b·=·new·byte[offset·+·length·*·Float.BYTES·-·TestUtil.nextInt(random(),·1,·Float.BYTES)]; +········byte[]·b·= +············new·byte[offset·+·length·*·Float.BYTES·-·TestUtil.nextInt(random(),·1,·Float.BYTES)]; This line is broken because it's too long and gjf tries to keep statements together (or vertically aligned, as you'll see in many other cases). If this bothers you then extract something to make the code read (and format) better: int length = offset·+·length·*·Float.BYTES·-·TestUtil.nextInt(random(),·1,·Float.BYTES); byte[] b = new byte[length] Is it more verbose? Sure. Is this a nicer read? Maybe. I've seen diffs where the nested expressions were humongous - very complicated to grasp as one-liners. I found them much more intuitive the way gcj formatted them (over multiple lines sometimes, indenting arithmetic and quotes for clarity). It's definitely biased towards shorter expressions than long ones involving multiple statements. Dawid --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
