Yeah - those single-line comments that were broken are mostly because they were just too long to fit in a single line. Other blocks (with shorter single-line comments) were just fine.
I've seen a couple other oddities resulting from //-type comments inside statements or right after variable declarations. These are wrapped in an unintuitive way too. I moved a few (so that they appeared before the variable) but otherwise didn't want to change too much. Like I said - these things can be corrected/ moved later on (and reformatted). > it's not always easy to coordinate sweeping changes while others continue to > mess around! True. That's why I wanted to have it done fairly quickly so that we can just move on. I'll finish one or two modules myself to get the corner cases right and then I'll probably ask for help. Viewing the diff a package-at-a-time takes fairly little effort (5-10 minutes) and it'd help enormously if we could somehow parallelise this effort over multiple people. I'll let you all know when I think it's ready; a day or two should be enough for me. Dawid On Tue, Dec 22, 2020 at 7:12 PM Michael Sokolov <[email protected]> wrote: > > 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 <[email protected]> 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: [email protected] For additional commands, e-mail: [email protected]
