Yes, that is what I saw; line breaking choices that are different than what I would manually have chosen. I don't mean to sound negative - this is a nice improvement that gets us away from having to fuss about indentation and other formatting. Even regarding these line breaks, it is sensible to have the control to insist that single-line comments are not merged where block comments are merged and reflowed, so we'll learn to adapt to its rules and get things looking the way we want. Thanks, Dawid for pushing ahead with this, it's not always easy to coordinate sweeping changes while others continue to mess around!
-Mike On Tue, Dec 22, 2020 at 12:49 PM Dawid Weiss <dawid.we...@gmail.com> wrote: > > > I see it there - yes, it makes some occasional widows, and sometimes > > fails to join up consecutive single-line comments (I think you > > mentioned this elsewhere) but I can live with it :) > > I review those diffs manually (for now at least). Some things are indeed > more verbose but I think they can be lived with (or corrected manually > at a later time). > > Single-line comments leave (typographical) widows when a long > single-line comment is broken because it exceeds line length. > To me the formatter intentionally doesn't treat consecutive > single-line comments as a block; it breaks long single-lines but > doesn't reflow them. So: > > // really really long comment on a single line > // that looks like this > > could be broken into: > > // really really long comment on a single > // line > // that looks like this > > I've seen examples when a reflow would actually corrupt the content of > the message so I guess no solution is ideal. If it's a block comment > then it should be a /* */ - then (again, I think) the content > undergoes a reflow. > > All this said, I think overall it's doing a great job, especially with > inconsistencies around operators, indents, javadoc etc. Sometimes it > tends to be verbose with method calls that have an insane number of > parameters (lining up over multiple lines). I've grown used to it - > it's really something you just live with after a while. And when it's > particularly bothersome, I just reformat the code somehow to have > fewer arguments, break long arithmetics into smaller local variables, > etc. This can be done gradually at a later time. > > So far I am pretty happy with what I've seen in those diffs though. > > Dawid --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
