System.out.println（）の使用がそれほど悪いのはなぜですか？[閉まっている]

もちろん、エラーメッセージまたは警告にログフレームワークを使用することは非常に有効です。ただし、短時間で新しいことを試してみたい場合は、System.out.println（）を使用することがあります。

System.out.println（）を使って簡単なテストを行うのは本当に悪いのでしょうか？

コメントで明らかになったように、求められている本当の質問は、なぜ静的コード分析ツールがSystem.out.printlnの使用にフラグを立てるのかということです。

理由は、標準出力にメッセージを送信することは通常、実稼働環境では不適切だからです。ライブラリをコーディングしている場合、ライブラリは標準出力に出力するのではなく、呼び出し元に情報を返す必要があります。GUIアプリをコーディングしている場合、stdoutが指す場所（どこにもないかもしれない）ではなく、情報をユーザーに提示する必要があります。サーバー（またはサーバー側のコンテナーで実行されるもの）をコーディングしている場合、フレームワークが提供するロギング機能を使用する必要があります。などなど。

しかし、デバッグまたは開発にprintlnを使用している場合、またはプログラムを作成してstdinを読み取りstdoutに書き込む場合、printlnはまったく問題ありません。これらの種類のケースでは何も問題はありません。

すべてがstdoutバッファリングされているので、ある可能プログラムがクラッシュすることをした後、あなたが呼ばれprintln()ますが、前にそれが画面に達します。

そうは言っても、このシナリオは本当にありそうもない。先に進んでそれを使用しますが、あなたの心の奥にある小さな制限を守ってください。

System.outラップされBufferedOutputStreamただけです。これは、使用するすべてのロギングフレームワークに類似している可能性があります。フレームワークは、ログ出力の構成と宛先の形式でより多くの機能を提供するだけです。

自明ではないプログラムに取り組んでいて、あなたが

• 自動化された単体テスト（JUnit）の代わりに松葉杖としてSystem.outを使用している
• System.outステートメントの作成と削除、またはコメント/コメント解除に多くの時間を費やす

System.out使い捨てコードであっても、の使用にはいくつかの注意事項があります。

1つの大きな問題は、通常遅いことです。たとえば、一部のコードの速度について大まかなアイデアを取得しようとしている場合（マイクロベンチマークは難しいことに注意してください）、System.out.println()どこにでも1つ追加すると、タイミングが台無しになる可能性があります（同期し、実際の出力を待つことが多いため）戻る前にユーザーに表示されます）。

それ以外は、使い捨てのコードではあまり心配しません。あなたはそれをコミットするつもりなら、あなたは（はい、それを取り除くとpropperロギングコールでそれを置き換える必要があり、（製品コードとして、あるいはテストコードとしても）でもテストコードで）。

よくあることですが、答えは「依存します」です。アプリケーションにロギングフレームワークがすでにある場合は、それを使用することもできます。の機能よりも劣ることはありません。またprintln()、スタックトレース、追加のコンテキスト、より優れた書式設定など、他の機能を利用することもできます。また、ロギングフレームワークがより優れたエラー回復を提供し、致命的な障害が発生した場合でもログが正常に書き込まれることを保証する明確な可能性があります。

したがって、最初にログシステムを追加するタイミングが問題になります。これは判断の呼びかけです。あまり早く追加したくないので、本当に必要がないかどうかを確認するだけです。また、追加するのが遅すぎて、アドホックソリューションから変換する作業が過剰になりたくないでしょう。

を使用して多くのログを記録しprintln()ていることに気付いた場合、コードベースは痛みが大きくなっていることを伝えようとしています。その時点で、適切なロギングに投資する価値があります。

System.out.printが「システムのデフォルト」コードページを使用するという問題がよくあります。これはLinuxではUTF-8であることが多いですが、WindowsではMSのものが一部欠けています。

これにより、プログラムの実行場所に応じて、画面に正しく印刷される場合とされない場合があります。

したがって、System.outよりもカスタムPrintWriterの方が好きです。

それはまったく悪くありません。この概念は、アプリケーションで専用のロギングフレームワークを使用するほど単純ではなく、洗練されていないという事実から生じる可能性があります。

ただし、これは無効なアプローチだと言っているわけではありません。ブラックマジックブードゥープログラミングのハイジャックの後、アプリケーションフローをチェックするために何度も使用しました。

それを使用することに何の問題もありません、それはあなたが「一体何が起こっているのか」を理解するのに役立ちます。

しかし、あなたの仲間/他の開発者/ツールがあなたをridしているなら、あなたはいつもLoggerを使うか、Junitテストを始めることができます！

職業System.out.printlnの最大の問題は、私が見るように、それが「悪い癖の匂い（tm）」であることです。これを実行していることに気付いた場合は、お気に入りのデバッガーをより快適に使用することで、おそらく有効性を向上させることができます。

また、デバッガーを使用すると、System.out.printlnが停止する可能性がある一方で、ブレークポイントが実動コードにスリップしないことが確実にわかります。

ちなみに、実際に簡単なテストを行っているだけで、デバッガーを使用しない場合は、ロギングフレームワークを使用するよりもSystem.out.printlnの方が優れていると思います。完了、根絶するのは難しい。

内部状態の内容のエコーアウトに関するテスト戦略全体を構築することは最も賢明な動きではありませんが、開発中のコードの迅速で汚れたテストのために、ここで奇妙なprintlnを削除します。

それらを削除するのを忘れる危険性は、おそらくそれが反対されている理由です。