メソッドがパラメーターの1つであるのを見るたびに、次のような出力パラメーターです
void addTokenErrorsToReport(List<String> tokens, Map<String, Integer> report)
これは明らかに間違っていると感じています。私の見解では、一般的にパラメーターは不変であり、メソッド内で変更されるべきではありません。たとえば、上記のメソッドは次のように書き換えることができます。
Map<String, Integer> createTokenErrorsReport(List<String tokens)
返さMapれたものは、元のレポート Map とマージできます。
この仮定は正しいですか？それとも、両方のバージョンが等しく受け入れられますか?
ほとんどの場合と同様に、機能が不十分/読み取り不能/保守が難しいコードにつながる場合、またはなぜそれを行っているのかわからない場合は、「悪い習慣」にすぎません。
ほとんどの場合、出力パラメーターを使用しても、これらの効果はありません。
addTokenErrorsToReport では、これは確かに適切なアプローチです。レポートにトークン エラーを追加しています。関数は、追加するトークンと追加先のレポートを認識する必要があります。この関数は、設計された操作を正確に実行し、欠点はありません。
createTokenErrorsReport アプローチを採用する場合は、既存のレポートに新しいトークンを挿入して、すべての呼び出しに従う必要があります。既存のレポートにトークンを追加することが一般的な操作である場合、追加するメソッドを持つことは間違いなく理にかなっています。createTokenErrorsReport も存在すべきではないと言っているわけではありません。トークン リストから新しいレポートを作成することが一般的な操作である場合は、それを行う関数が必要になります。
出力パラメーターの適切な使用例はCollections.sort、リストをその場でソートする です。リストの新しいコピーを作成してソートされたコピーを返すことによるパフォーマンスの低下は回避されますが、同時に、必要に応じてコピーの作成とコピーのソートを制限することもありません。
仕事に最適なツールを使用して、コードを簡潔に保つだけです。
2 番目の例のマップに何かを追加するにはどうすればよいでしょうか? 塗りつぶされた空のマップを渡す必要がある場合、それは悪い習慣だと思いますaddTokenErrorsToReport。しかし、この場合: いいえ、悪い習慣だとは思いません。List<String> tokens処理したいものがいくつかある場合、そうでなければどのように実装しますか? 最初の例は単純なものだと思います。
出身地（言語）によると思います。ポインターをパラメーターとして使用できる c または c++ を書いていた場合、これは素晴らしく実用的であり、最初の例のようなコードを簡単に書くことができます。ある種の良い悪いがあるとは思いませんが、あなたのコーディングスタイルはどうですか.
私はこのコーディング方法をかなり頻繁に見てきましたが、非常に洗練されていると感じました。複数のオブジェクトを「返す」ことができます。
たとえば、上記の例では、エラー コードに対応する整数値を返すことができます。