Nombramiento de métodos bool: Is vs. Can vs.?

Es vs. Can

Según las recomendaciones de la convención de nombres de Microsoft , ambas " Is "y" Can "están bien (y también lo es" Has ") como prefijo para un booleano.

En un lenguaje sencillo, "Is" se usaría para identificar algo sobre el tipo en sí, no sobre lo que puede hacer. Por ejemplo, IsFixed , IsDerivedFrom , IsNullable se pueden encontrar en los tipos y métodos CLR. En todos estos casos, "Is" va seguido de un adjetivo .

Mientras tanto, "can" indica más claramente una capacidad, por ejemplo, CanEdit , CanRead , CanSeek . En cada uno de estos casos, puede ir seguido de un verbo .

Ya que "Soporte" es un verbo, creo que en tu caso CanSupportContentType es mejor.

Alternativa más corta

Por otro lado, las convenciones dicen que el prefijo es opcional. Lo que es más, es un poco cursi incluir el tipo de argumento en el nombre del método, ya que un desarrollador puede ver el tipo del argumento en intellisense. Entonces, podría simplemente nombrar su método Supports y definirlo de la siguiente manera:

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

... que es más corto y aún comunica claramente el propósito. Lo llamarías así:

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

O como compromiso, quizás esto sea lo mejor:

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

Vale la pena mencionar que también se puede usar el prefijo " debería ". De acuerdo con guía de Apple , no solo " puede "y" deberían ", los verbos modales en general se pueden usar para nombrar funciones que devuelven el valor booleano. No puedo ver el uso de " will " pero " debería " es bueno para los ganchos de consulta de consejos, como se ve en reactjs:

shouldComponentUpdate: (newProps: any) => boolean