(これが再投稿である場合は事前に謝罪しますが、同様の投稿は見つかりませんでした)
コードで見た悪いメソッド名のパターンと、コードについて何を教えてくれましたか。
たとえば、私は見続けます:
public void preform___X___IfNecessary(...);
操作 X には条件の反転があるため、これは悪いことだと思います。クラスメソッドはこのようなプライベートヘルパーを合法的に必要とする可能性があるため、これはパブリックメソッドであることに注意してください
(これが再投稿である場合は事前に謝罪しますが、同様の投稿は見つかりませんでした)
コードで見た悪いメソッド名のパターンと、コードについて何を教えてくれましたか。
たとえば、私は見続けます:
public void preform___X___IfNecessary(...);
操作 X には条件の反転があるため、これは悪いことだと思います。クラスメソッドはこのようなプライベートヘルパーを合法的に必要とする可能性があるため、これはパブリックメソッドであることに注意してください
時には、開発者が簡潔な言葉遣いに問題を抱えているように見えることもあります。私には手順に名前を付けた人がいました
InsertImportQueueRecord
私はその名前が嫌いでした。に変更しました
ImportItem
前者は単純な概念を表現するために退屈な表現を使用するだけでなく、実装の詳細を不必要に明らかにします。発信者は、キューが使用されていることを知る必要はありませんでした。知っている場合は、 のような名前を付けるか、アイテムのインポートがキューに入れられているQueueItemImport
かScheduleImport
スケジュールされていることを指摘します。また、レコードを挿入するという概念は実装上の言語であり、問題ではないため、避ける必要があります。
thing()、doThing()、reallyDoThing()
これは、関数が何をすべきかについて人々が完全に明確ではない場合に見られます。最初にアクションが必要かどうかを確認したり、キャッシュを更新したり、変更通知を送信したりします。知るか?
これは、メソッド名を変更したくないことが原因である場合があります。私はこれが嫌いです。関数は、彼らがするように聞こえることをするべきです。とにかく機能を大幅に変更する場合は名前を変更するため、すべての呼び出し元を修正する必要があります。
私が最近気付いたもう1つの方法は、次の形式のプライベートメソッドの束です。
private void SOMETHINGBecauseOf__a__(..);
private void SOMETHINGBecauseOf__b__(..);
private void SOMETHINGBecauseOf__c__(..);
メソッドにBecauseOfを含めることも、同じようなことをすることも、正当な理由を考えることはできません。これは、1つのメソッドのswitch/ifステートメントの良いケースのように見えます。
簡潔なメソッド名が見つからない場合は、メソッドがやりすぎていることを示しており、リファクタリングを検討する必要があります。
明らかな例はValidateFormData_PersistToDB_SendEmail()
.
私は C# 開発者なので、あえてアンダースコアを使用するつもりはありません。