+0 I've never found these comments caused any problems for me but if the consensus is that it slows down things for others, I have nothing against removing them.
-- Michael Mior [email protected] Le lun. 10 sept. 2018 à 04:49, Vladimir Sitnikov < [email protected]> a écrit : > Hi, > > Could we have a vote on coding style regarding "// End File.java" in > Calcite source files? > "//End..." comments clutter Git history, they consume screen space, and > they slow down the development by causing Checkstyle violations. > > Could we vote on the style regarding "//End File.java" > > [ ] +1, remove the ending "// End File.java" comment, ensure files end with > single blank line > [ ] -1, keep "// End File.java" since ... > > > https://www.apache.org/foundation/voting.html#votes-on-code-modification > > Whole numbers are recommended for this type of vote, as the opinion being > expressed is Boolean: 'I approve/do not approve of this change.' > >... > > A veto without a justification is invalid and has no weight. > > > Note back in 2014 Julian did mention 5 thoughts which are questionable. > > Julian>And it helps ensure that the file ends with a line ending. > > This is just false. The comment line has nothing to di with line ending. > A rule of "file must end with a single blank line" can be verified without > "dedicated comment line". > > Julian>It indicates the name of the file (useful if the file has been > renamed). > > If a file is renamed, then ending comment HAS to be updated otherwise > Checkstyle fails the build. > In other words, comment always matches "current" file name, thus it cannot > help to detect renames. > > Julian>The comment makes it easy to see that you are looking at the last > page of a file in an editor. > > This is true, however it does sound like a very rare use-case for me. > Editors often show file name on their own (tab name, application title, > navigation gutter). > Of course, certain UI elements in the IDE can be disabled, however I sill > think IDE is much better at telling you which file you are looking at than > a comment in the very last line of the file. > > If we follow that logic, should we add "filename comment" after each 25 > lines so one always knows which file is open? That is just non-sense. > > Julian>It verifies that the file has not been truncated > > If the file is truncated, the compiler will bail out. Unit test could > detect that as well. > On the other hand, "ending comment" does not protect from accidental cut > from a middle of the file. > > Julian>and provides a buffer against truncation issues. > > I don't get it, however it mentions truncation, thus I assume that is not a > valid justification. Truncation is to be managed by Git / code review / > compiler / test suite. > > Vladimir >
