[
https://issues.apache.org/jira/browse/CALCITE-490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14237269#comment-14237269
]
Vladimir Sitnikov commented on CALCITE-490:
-------------------------------------------
While I appreciate different use cases, I still find no good reason to keep
those comments.
My points against:
1) I do not find this kind of conventions in Google java guidelines/OpenJDK.
2) I find it inconvenient to support. It is not that often when I need to
update the header, however I still need to keep that in mind.
3) It consumes space. For instance, if I scroll to the very bottom, then my IDE
shows those "blank line + end file.java" instead of two meaningful lines of
code.
4) It complicates diffs by adding noise lines.
{quote}it easy to see that you are looking at the last page of a file in an
editor{quote}
When "editor" is IDE, then you have the file name always visible by default. I
am not sure how often you are starring at the very bottom of the file trying to
understand "what class I am looking into?".
{quote}It verifies that the file has not been truncated, and provides a buffer
against truncation issues{quote}
I do not get this. Are those issues often? Typically, git shows the differences
in a nice way, so I see no reason of having some "spare lines" "just in case".
You might delete a line from the middle of the file by accident and this buffer
won't help.
I do not think this buffer would protect from "out of space" issues, since if
you are out of space, then much more severe issues will arise (unable to write
git index, etc)
{quote}It indicates the name of the file{quote}
It is not the master source of the data, so this file name might even be
misleading.
{quote}(useful if the file has been renamed){quote}
If that comment included "all the previous names", theoretically it could make
sense.
However,
1) Renames can be tracked in git history and/or in spreadsheet for "the great
rename".
2) If the previous name is really important, then it should be tracked in
release notes and/or in javadoc.
3) I just picked ProjectFilterTransposeRule at random, and it turns out to have
"// End ProjectFilterTransposeRule.java" comment. No sign of "previous file
name".
{quote}And it helps ensure that the file ends with a line ending.{quote}
That is very good point. For esthetic reason I hate when files end without
newline.
However, I believe just a checkstyle kind of rule would do better to ensure the
files are terminated in a consistent way (e.g. no lots of blank lines, no
whitespace, etc)
> Remove "End File.java" comments from the end of files
> -----------------------------------------------------
>
> Key: CALCITE-490
> URL: https://issues.apache.org/jira/browse/CALCITE-490
> Project: Calcite
> Issue Type: Bug
> Reporter: Vladimir Sitnikov
> Assignee: Julian Hyde
> Labels: newbie
>
> Make sure the files end with just a single blank line.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
