私の現在のプロジェクトでは、Javaソースファイルの最後に常に空の新しい行を挿入します。これをCheckStyle(エラーレベル付き)で強制します。
私は長い間このトピックを探していましたが、残念ながら、これについて説得力のある理由は見つかりませんでした。他の開発者はEclipseフォーマッターで1つのチェックボックスをオンにしただけで自動的に行われるため、これについては無関心であるようです。しかし、なぜそれが必要なのか、なぜそれが重要なのかはまだわかりません)。だから私の質問は:
Javaソースファイルの最後に空の行が必要なのはなぜですか?それは現在の必要性ですか、それとも過去の遺物であり、現在のコードベースでは望ましくありませんか?
私は彼らがすべてのファイルが末尾の改行文字で終わるようにしようとしていると思います。これは、空白行、別名空の改行で終了することとは異なります。
編集:@Easy Angelがコメントで簡潔に明記されているように:末尾の改行= "\ n"および空白行= "\ n\n"
私はどちらかと思います:
あなたのリードは、すべてのファイルが改行文字で終わることを義務付けていますが、すべてのファイルが空白行(つまり、改行で終わる空の行)で終わることを義務付けていると誤解されています。
彼らは、実際にすべてのファイルの終わりを空白行(別名、改行で終わる空行)で強制することにより、すべてのファイルが改行文字で終わることを確実にし、それによってファイルが少なくとも1つの改行で終わることを保証します?)。
エディターが実際に改行記号を表示しない限り、一部のエディターではファイルが常に明確であるとは限りません。
最近のほとんどのソースコードエディターは、末尾に改行を挿入すると思います。ただし、より古い一般的なエディターを使用すると、 私は常に、ソースコードファイル(および一般的なテキストファイル)が常に末尾の改行で終了するようにしようとしました(使用しているエディターによっては、空白行または空の改行として時々出力されました)。
cat
を使用してコマンドラインにファイルを表示する場合、ファイルの末尾に改行がないと、次の出力(シェルプロンプトまたはスクリプトがファイル間で出力する可能性のある視覚的な区切り文字など)は、直後に表示されます。改行ではなく、最後の非改行文字。一般に、末尾の改行により、ファイルはユーザーおよびスクリプトにわかりやすくなりました。
一部の編集者(詳細を思い出せません)は、テキストファイルに改行がない場合、末尾の改行を自動的に挿入すると思います。これにより、ファイルが変更されたように見えます。さまざまなウィンドウで多数のファイルを開いてからそれらをすべて閉じると、混乱を招きます-エディターは保存を求めるプロンプトを表示しますが、ファイルに「実際の変更」を行ったか、それとも自動改行を挿入しました。
diff
のようないくつかのツールと一部のコンパイラーは、末尾の改行がないと文句を言うでしょう。これは、ユーザーとツールが対処しなければならない可能性があるより多くのノイズです。
編集:
エディターが改行を追加し、ファイルの最後に改行と空の改行があるかどうかを確認できないことについて、私はVim、Eclipse、およびEmacs(Cygwinを使用するWindowsシステム上)をテストしました:新しいファイルを開き、「 h '' e '' l '' l '' o '[ENTER]を押すことなく保存されます。各ファイルをod -c -t x1
。
だが
好きなように解釈してください。
私の個人的な習慣は、テキストファイルが末尾の改行で終わるようにすることです。 最小の驚きがあると感じているだけで、これがそうです。この点では、ソースファイルをテキストファイルとまったく同じに扱いません。
Googleが表示される this :
これは、この編集の時点で、Cコンパイラ、svn(diffのため)、diffなどからの後続の改行の欠落に関する警告についてのヒットを示しています。テキストファイル(ソースファイルが含まれる)で終わるという一般的な期待があると感じています末尾の改行と、そこにある傾向があるときに最も驚くべき(そして騒々しくない)。
最後に this は興味深いです:
末尾に改行がないサニタイジングファイル
テキストファイルのすべての行は、改行文字(\ n)で終了する必要があります。これはPOSIXで述べられており、テキストファイルはゼロ以上の行に編成された文字を含むファイル。
次に、線は次のように定義されます
*ゼロ個以上の非文字のシーケンスと終了文字。
[〜#〜]ただし[〜#〜]とは言っても、これは私の個人的な習慣にすぎません。私は私の意見を尋ねる人に共有することを嬉しく思いますが、私は誰にもこれをあざけません。私が言うように、これは義務化する価値があるものだとは思いません here :
私は一貫性のあるすべての人ですが、すべてのスタイルを細かく管理することにも反対しています。コーディング規約の膨大なリストがあることは、特にそれらが恣意的であると思われる場合は、人々がそれらに従うのを思いとどまらせる原因の1つです。コーディングガイドラインは、非効率性を改善する最も価値のある方法に合理化されるべきだと思います。この方法を義務付けることで、可読性、保守性、パフォーマンスなどはどの程度改善されますか?
最後に余分な改行を入れる理由は次のとおりです。
最後に改行がないファイルがある場合、次にファイルを編集して別の行を追加すると、ほとんどのマージツールは既存の行が変更されたと見なします(SVNも変更することは90%確信しています)。
以下の例では、「編集前の最後の行」を含む行には改行がありません。 「編集後の最後の行」という新しい行を追加しようとすると、5行目と6行目の両方が変更済みとしてマークされていることがわかりますが、両方のバージョンの5行目の実際の内容は同じです。
全員がプロジェクトリードの提案に従っている場合、これが結果になります(6行目のみが元のファイルと異なる)。これにより、マージ中の誤解も回避されます。
これは大したことではないように見えるかもしれませんが、ある開発者(A)が実際に最後の行の内容を変更するつもりで、別の開発者(B)が新しい行を追加したとします。 EOFの前に改行を使用しない場合、開発者Bは前の最後の行も編集して改行を追加する必要があったため、マージの競合が発生します。そして... CVS/SVNの競合は誰が好きですか?
this SO question。 をご覧ください。
ラルフリッケンバッハから恥知らずに盗まれた答え:
テキストファイルのデータの最後の行が改行または改行/改行の組み合わせで終了していない場合、多くの古いツールは正しく動作しません。代わりに^ Z(eof)で終了しているため、その行は無視されます。
だから私はそれがほとんど過去の幽霊だと思います。残念ながら、そのような幽霊は、適切に体を鍛えないと、尻尾を噛む可能性があります。 (ビルドサーバーは古く、要約などに古いシェルスクリプトを使用しています)。
ファイル全体をカット/ペーストしてみてください。 checkstyleまたはEclipseのバグ:)
コンパイラが正しく解析しない場合があります。
Error: Reached end of file while parsing
末尾に改行文字が含まれていることについてすでに述べた有効な理由(古いツールとdiffで発生する可能性のある問題)とは別に、それを調べる別の方法を次に示します。
ファイルのnot other lineに改行文字が追加されているのに、notで最後の行を特別な場合に追加するのはなぜですか?
一部のC++コードでは、コンパイラーが警告を生成し、「エラーや警告はありません」というポリシーがあったため、これを行わなければなりませんでした。たぶん問題は別の場所にあります...あなたは差分ツールが問題を処理していますか、それを処理できないマージツールですか?
たいしたことではありません。
それは単なるコーディングスタイルです。何も傷つけたり助けたりしません。私はあなたがあなたのチームの好みで空行を含めるように聞こえることを気にさせません。なぜ誰かが実際にそれをcheckstyleに追加するのに十分気にかけているのかを除いて、それに対して本当に良い議論はありませんか?
そのような要件について聞いたことがありません。
実際、Javaプログラムは、ファイルの最後に空白行がない場合、コンパイラ/ランタイムエラーや警告なしに実行されることを確認しました。
一部のコメンターが言ったように、これはコーディングスタイルの問題であるに違いありません。残念ながら、Javaのファイルの最後に空白行があることがなぜ重要であるのかについてはお勧めできません。実際、それは私にはまったく意味がないようです