メソッド名での接続詞の使用が悪い命名規則なのはなぜですか？[閉まっている]

私のチームでは、数人のソフトウェアアーキテクトと緊密に連携しています。彼らは私たちのプロジェクトのすべての設計決定を承認し、コードレビューなどを行います。

私たちのプロジェクトは、主にSymfony 2フレームワークを使用してPHPで実装されたバックエンド機能で構成されています。そのため、構文的には、コード、命名規則、およびプロジェクト構造は、Javaがどのように見えるかとほぼ同じに見えます（Symfony 2はそのような構造を推奨しています）。Java固有の規則もこのケースに適用されるため（可能であれば）、これについて言及しています。

最近、彼らは私が非常に奇妙だと思うことを提案しました：すべてのメソッドはgetEntityOrNull、例えば、setValueOrExceptionなどの名前に接続詞を持つべきです

このような命名規則は私にとって非常に間違っているように感じますが、具体的な議論や、これに特に挑戦するオンラインの記事/ページを思い付くことができません。

私が思いついた唯一のものは：

• そのような情報は次のように、メソッドの注釈中に存在すべきです@returnか@throws
• メソッド名に接続詞（「and」、「or」など）を使用すると、通常、単一責任原則が適切に尊重されないことが示唆されます。

この命名規則に対する他の具体的な議論は何ですか？

彼らはおそらく名前の競合のためにそうしています。getEntity例外をスローする可能性のあるメソッドと戻る方法の2つのメソッドを持つことはできないと思いますnull。したがって、それに応じて名前を付ける必要があります。

私は、その特定のクラスのみが実行できる何らかの変更を実行していない限り、同じメソッドを呼び出す多くの異なる方法を持つ習慣を嫌います。

言い換えると、getValueOrNullが単にを呼び出しgetValueOrException、例外をキャプチャし、その場合にを返す場合null、これは呼び出し側によって実行できます。それはクラスを本当に有用なものに貢献しないメソッドで混乱させます。むしろ、を好みgetValue、例外をスローすることを知っています。さらに良いのは、すべてのgetメソッドが例外をスローする可能性があり、nullプロジェクト全体で振る舞いが均一になるようにそれらのいずれも返さないこと、または逆にすべてが潜在的に戻ることnullを知り、呼び出し元が例外をスローする必要があることを知っていることを好むそれが望まれていた。

ただし、あなたがそれを担当していないことも事実です。私のアドバイスは、それを持ち出すことですが、ささいなことは気にしないでください。最終的に、そのような命名規則の責任は、彼らがあなたのアドバイスをとるかどうかに関係なく、彼らの肩にかかっています。そして、それは彼らのライン上のロバなので、私は謙虚な意見でノーと言うのは特権だと思います。

接続詞の使用は多くの場合、SRPの違反を示しますが、この場合は、2つの値、nullまたは「成功」値のいずれかになる可能性のある、貧乏人の代数データ型の戻り値を示しています。

彼らは、ある種のハンガリー記法を使用して、型システムの弱点、つまり、nullできない型の不足を補っています。言い換える@returnと、関数が決して戻らないことを注釈で指定する方法はなくnull、逆に@return、関数が戻る可能性があることを注釈で指定する方法はありませんnull。

また、@throws注釈はPHPでは必須ではないので、注釈がないことは例外がないことを示していませんが、スタイルガイドで注釈を必須にすることで解決できます。

使用している言語のこれらの制限を考えると、それは完全に不合理なスタイルではありません。

私のコードでは、getEntity（）やgetEntityOrNull（）などの名前のメソッドペアを作成することがあります。この名前により、予期される動作が明確になります。getEntity（）がエンティティを検出しない場合、例外がスローされます。getEntityOrNull（）はnullを返します。

これにより、呼び出し元のコードが少し明確になります。呼び出し元のコードにエンティティが必要な場合、getEntityがトリックを行います。entityが何らかのオプションのものである場合、getEntityOrNullが選択方法です。

同じことが単一のメソッドで実現できますが、それは呼び出しプログラムに負担の一部をシフトします。ヌルを常にテストするか、try / catchブロックが必要です。いずれにせよ、メソッドが呼び出されるたびに複製する必要がある追加のコードです。

あなたのアーキテクトがこれらの種類のメソッドペアを使用していない場合は、はい、サフィックスの必要性について疑問を呈します。

setValueOrExceptionメソッドを実際に見たことはありません。そのための良い一般的なユースケースを考えることはできません。

建築家にその理由を尋ねることを検討してください。私が知っている人は、彼らの決定を説明するのをいつも喜んでいます。多くの場合、非常に詳細な（そして時には耐え難い）詳細です。

あなたの2つの議論は健全です。ただし、命名規則の決定を担当しているのであれば、あなたが同意しないものであることについてあまり気にしないようにしてください。

その間、これらのメソッドが実際にメンバー変数を直接設定または取得しない限り、「get」および「set」部分を使用しないように説得する必要があります。