Layout is semantic, just as names and comments are. I don't want a tool to blindly stomp any of these when it lacks understanding how they benefit readers.
The answer to dirty diffs is to not make them. Every change should be intentional, and a reviewer should agree that it's important. "Reformat this block I haphazardly edited" is fine, but don't make the change bigger for no reason.
> I don't want a tool to blindly stomp any of these when it lacks understanding how they benefit readers
Some dev will have 1 newline after a method ends, another dev will have two newlines, some might have 3 etc. Should you as a code reviewer be wasting time looking for such issues and putting comments tell the other to fix such issues?
It’s not my job to make you write exactly what I would have. I don’t care about an extra blank line, and I expect a reviewer to accept that it doesn’t matter. I draw the line at layout that is misleading about the code (e.g., dangling else that doesn’t parse the way it’s indented).
Yes layout is semantic and the automatic layout configuration should not be random nonsense. Configure a style that makes sense and apply it.
I've never seen that code that needed to be weirdly formatted with its own rules separate from other files in the codebase in order to make sense. That just sounds like a developer being a prima donna with their code style, not something that genuinely improves understanding and collaboration.
System.arraycopy(src, srcPos, // from
dest, destPos, len) // to
where I want to show the parallel relationships between src/srcPos and dest/destPos. Blind tools don’t know to do this, they either emit one long line or waste seven lines.
Tools also won’t know how to format a DSL well at all, which has already been a problem with Spark jobs in Scala.
Meh. That is so obvious to anyone who would use that function. Just put it on one line.
If your function has too many parameters then the code probably needs refactoring.
Yes agreed about DSL in Scala. Scala is complicated. I was a Scala dev for many years. We tried to avoid the more academic and overly abstract designs with that language.
