-0 I don’t think it’s worth getting into debates about coding style.
> On Sep 10, 2018, at 1:12 PM, Josh Elser <[email protected]> wrote: > > -0 I don't see this as a burden as you do, but don't feel strongly either way. > > On 9/10/18 4:49 AM, Vladimir Sitnikov wrote: >> 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
