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
