タイトルは少しあいまいかもしれませんので、説明させてください。ファイルを作成する関数など、何かを行う(プログラムの状態を変更する)関数があるとします。この関数は、ファイルが作成された場合はTrueを返し、ファイルが作成されなかった場合はFalseを返します。
次に、その関数を条件付きで使用します。たとえば、次のようにします。
if (createFile() == false)
// log: we cannot create file
また、次の方法でも実行できます。
boolean fileCreated = createFile()
if (fileCreated == false)
// log: we cannot create file
問題は、最初のケースが2番目のケースよりも可読性と明瞭性の点で劣っているかどうか、そしてどのケースを使用することが推奨されるかです。
私の推論は、コードを読んでいる誰かが関数の内部に慣れていない可能性があるため、最初のケースでは、関数createFile()が状態を変更しないと想定する可能性があるためです(これらの関数は述語関数であることが多いため)?
これは少し判断の呼び出しですが、メソッドの早い段階でcreateFile()
を呼び出す必要がある場合は、結果を変数に格納する方が少し良いと思います。これは、誰かが後でコードを更新し、fileCreated
状態を確認する必要がある場合、既存のコードブロックから条件をコピーすることが一般的であるためです。メソッドを直接使用する場合、エディターは変数を導入し、既存の条件を更新する必要があります。本当に世界の終わりではないので、私はそれに夢中にならないでしょう。最後のステートメントがreturn createFile()
だった場合、変数は導入しません。
実際には、メソッドで同じ条件を複数回チェックする必要がないことが望ましいので、それを完全に回避することが最適です。それは上記を無意味にするでしょう。だから、それは本当にカットアンドドライではありません。チームのスキルレベルによって異なります。
私は関連していますが、ケースは異なりますが、メソッドが何も変更せず、呼び出しごとに異なる結果を返す可能性がある場合でも、多くの場合、正確さのために結果をローカルにキャプチャする必要があります。
私にとって、主なコードのにおいは、createFile()
メソッドが成功を示すブール値を返すことです。 1970年代のプログラミングスタイルを思い出します。
createFile()
という名前のメソッドは、ファイルを作成するという契約を意味します。それができない場合、契約は履行されておらず、メソッドは例外をスローする必要があります。ブール値を返すバージョンでは、現在のプログラミング方法に慣れている少し不注意なユーザーがその名前を確認してメソッドを呼び出し、ブール値の戻り値を無視して、ファイルが作成されていると想定します。
契約で特定の状況下でファイルを作成できないようにする場合は、名前にそのことを示す必要があります。 createFileIfPossible()
のように。
通常、ユーザーコードは、続行するために必要であるため、ファイルを作成します。したがって、デフォルトの例外処理は必要なものであり、続行する方法がわかっている場所まですべての計算を中止します。そこにキャッチを配置し、そこに例外を記録します。そうすれば、質問のコードフラグメントは不要になります。
関数からの戻り値を変数に保存するのではなく、直接使用することは、一度だけ必要な場合は完全に問題ありません。実際、不要なアーティファクトを導入しないことは良い考えです。そのため、それらを追跡できなくなったり、不適切な名前を付けたりすることはできません。
うまくいかないのは、その関数名です。私はそれがbool
ではなくFile
を返すとは期待せず、失敗すると例外をスローします。それをサポートする言語では、それはおそらく俳優であるべきです。
または、tryOpenFile()
に名前を変更することも可能です。
もう1つの奇妙な点は、ファイル名に引数がないことです。
実際の呼び出しは無視してください。これらは実装の詳細であり、処理する必要があるためです。最初のタスクは次のとおりです。どちらかファイルを作成し、ブール値の "fileCreated"をtrueに設定しますorファイルを作成しようとして失敗しました。ファイルを作成しようとし、ブール値の "fileCreated"をfalseに設定しました。
2番目のタスクは次のとおりです。ファイルが作成されなかった場合は、その事実をログに記録します。
次に、2番目のタスクのコードを記述します。最初のタスクのコードを記述しなくても、これを実行できるはずです。その結果、「if(createFile()== false)のような条件を設定することはできません。最初のコード例は、ファイルの作成とテストを混同したものです。これはほんの少しのコードでしたので、問題はありません。 、しかしそれはより大きなケースでは醜くなります。
コードは読みやすくする必要があります。開発者にコードで実際に起こっていることを見つけさせようとすると、何かがおかしいのです。
どちらの場合も判読可能ですが、これは改善できないことを意味しません。 「ファイルを作成する」の戻りが意味の点でそれほど明白ではないことを理解しています。私の考えは、コードをより自然に読み取るために(変数の代わりに)新しいメソッドを作成することです。
だから、あなたは少し改善することができます:
if (!isFileCreated(createFile())
// log: we cannot create file