boolメソッドの命名：vs. can vs.？

ブール値を返すメソッドのより良い名前はどれですか？

IsSupportContentType

または

CanSupportContentType

naming naming-standards

— 調停者
ソース

名前は状態または動作を明確に伝えるためのものであり、「このクラスはコンテンツタイプXをサポートしている」とは決して言えないため、より良い名前はCanSupportContentTypeです。「このクラスはコンテンツタイプXをサポートできます」などと言うでしょう。

— クレイグ

ネイティブスピーカーではありませんが、 SupportContentTypeは最も「文法的な」オプションではありませんか？

— ローマンライナー

最初はIsSupportedContentType文法的に正しいことでなければなりません。（「サポートコンテンツタイプ」が名詞として機能しない限り、これはありそうにない）

— -CodesInChaos

単純にsupportsContentTypeどうですか？以下は完全に読み取り可能ですif (abc.supportsContentType("text/html"))。「サポート可能」は、コンテンツタイプをサポートするためのさらなる条件があることを意味します。

— オリビエグレゴワール

@WeylandYutani IsCanHasSupportCheezburger？

— RM

回答:

106

対缶

マイクロソフトの命名規則の推奨事項によれば、ブールのプレフィックスとして「Is」と「Can」はどちらもOKです（「Has」も同様です）。

平易な英語では、「できる」ではなく、タイプ自体について何かを識別するために使用されます。たとえば、IsFixed、IsDerivedFrom、IsNullableすべてのCLR型およびメソッドで見つけることができます。これらすべての場合、「Is」の後に形容詞が続きます。

一方、より明確例えば、能力を示す「できます」CanEdit、CanRead、CanSeek。これらの各ケースでは、canの後に動詞が続きます。

「サポート」は動詞なので、あなたの場合CanSupportContentTypeはより良いと思います。

より短い代替案

一方、慣例では、プレフィックスはオプションです。さらに、開発者はインテリセンスで引数のタイプを見ることができるため、メソッド名に引数のタイプを含めるのはちょっと安っぽいです。したがって、メソッドに名前を付けて、次のように定義することができますSupports。

public bool Supports(System.Net.Mime.ContentType contentType)

...これは短く、それでも目的を明確に伝えます。次のように呼び出します。

ContentType contentType = new ContentType("text/plain");
var someClass = new MediatorsClass();
bool ok = someClass.Supports(contentType);

または、妥協案としてこれが最善かもしれません：

public bool CanSupport(System.Net.Mime.ContentType contentType)

— ジョン・ウー
ソース

よく読めるといいですねif ( someClass.Supports(contentType) )

— 。– candied_orange

…またはhasSupportedContentType

— ベルギ

"CanSupports" initialltyというメソッドは、ソフトウェアが缶をサポートできるようにするのに誰が時間を費やしたのかと思いました（ブリキ缶のように）。まさに「サポート」がより良い選択肢です、間違いなく！

— T. Sar-モニカを復活させる

開発者は、英語が母国語ではない場合など、何かが「奇妙に聞こえる」と判断できない場合があります。

— ジョン・ウー

短いバージョンの方が悪い場合があります。たとえば、C ++標準ライブラリがありstd::vector::empty()ます。その名前だけから、ベクトルを空にしますか？または、ベクトルが空かどうかを返しますか？前者のタスクはによって実行されるため、実際は後者std::vector::clear()です。ただし、一般的にドキュメントを読んで確認する必要があります。反対の例として、QVector空のチェック方法がであるため、Qtの方がこの点で理解しやすいですQVector::isEmpty()。

— ルスラン

「should」プレフィックスを使用することもできます。Appleのガイドラインによると、「can」と「should」だけでなく、モーダル動詞を使用してブール値を返す関数に名前を付けることができます。私は「will」の多くの使用を見ることはできませんが、reactjsで見られるように、「should」はアドバイスを求めるフックに適しています：

shouldComponentUpdate: (newProps: any) => boolean

— ハリー
ソース

べきでは私見かなり貧しい命名、「まあ、それはすべき文書を閉じて、私は実際には非常によく分からない」

— ロヴィス

@lovis：ハリーのコメントは非常に有効だと思います。たとえば、プラグインレイヤーを介してデータベース関連のアクションを委任できます。各プラグインには、クリーンアップを実行する必要があることをフレームワークに通知する「ShouldCloseConnection」メソッドがあります。単なる例ですが、「should」は間違いなく有効なプレフィックスです。

— グレッグ

@gregどのように曖昧さが少なくなっていWillCloseConnectionますか？

— 基本的な

@Lovis一般的に使用しますis...がshould...、一部の関数の引数名では、ブール値が関数が物事を変更するものを示す場所で使用します。関数がオプションでドキュメントを閉じることisClosedができ、正確なパラメータ制御（まだ閉じられていない）を呼び出すのでshouldClose、これが関数が行うことを示すために使用します。（任意の例。特にドキュメントを閉じるには、専用の呼び出しを行うのに十分な重量があるはずなので、このような関数はおそらくありません。）

— KRyan

@Basic少なくともこのケースでwill...は、promiseを返す非同期関数用に予約されています。前のコメントで説明した関数が同期的である場合、using will...は命名と矛盾します。

— KRyan