Nombramiento de los métodos bool: ¿es vs. puede vs.

¿Cuál es el mejor nombre para un método que devuelve un valor booleano?

IsSupportContentType

CanSupportContentType

naming naming-standards

— Mediador
fuente

Como la intención es que el nombre transmita claramente el estado o el comportamiento, y nunca diría "esta clase es contenido de soporte tipo X", el mejor nombre es CanSupportContentType. Diría algo como "esta clase puede admitir contenido tipo X".

— Craig

No es un hablante nativo, pero no sería ¿El SupportContentType ser la opción más "gramatical"?

— Roman Reiner

El primero debería ser IsSupportedContentTypeser gramaticalmente correcto. (a menos que "tipo de contenido de soporte" actúe como un sustantivo, lo que parece poco probable)

— CodesInChaos

¿Qué tal simplemente supportsContentType? El siguiente es totalmente legible: if (abc.supportsContentType("text/html")). "puede soportar" implica que existen otras condiciones para soportar el tipo de contenido.

— Olivier Grégoire

@WeylandYutani IsCanHasSupportCheezburger?

— RM

Respuestas:

106

Es vs puede

De acuerdo con las recomendaciones de la convención de nomenclatura de Microsoft , tanto "Es" como "Puede" están bien (y también lo es "Tiene") como prefijo para un booleano.

En inglés simple, "Is" se usaría para identificar algo sobre el tipo en sí, no lo que puede hacer. Por ejemplo, IsFixed, IsDerivedFrom, IsNullablese pueden encontrar en tipos y métodos CLR. En todos estos casos, "Is" es seguido por un adjetivo .

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

Como "Soporte" es un verbo, creo que en su caso CanSupportContentTypees mejor.

Alternativa más corta

Por otro lado, las convenciones dicen que el prefijo es opcional. Además, es un poco cursi incluir el tipo de argumento en el nombre del método, ya que un desarrollador puede ver el tipo de argumento en intellisense. Así que podrías nombrar tu método Supportsy definirlo así:

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, tal vez esto sea lo mejor:

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

— John Wu
fuente

Es agradable cuando se lee bien:if ( someClass.Supports(contentType) )

— candied_orange

... ohasSupportedContentType

— Bergi

Un método llamado "CanSupports" hace que me pregunte quién pasó tiempo haciendo que el software sea capaz de soportar latas (como en latas). Solo "Soportes" es la mejor opción, sin duda.

— T. Sar - Restablece a Monica

A veces los desarrolladores no pueden saber cuándo algo "suena raro", por ejemplo, si el inglés no es su lengua materna.

— John Wu

A veces una versión más corta es peor. Por ejemplo, en la biblioteca estándar de C ++ que tenemos std::vector::empty(). Solo por su nombre, ¿vacía el vector? ¿O devuelve si el vector está vacío? En realidad, la última, ya que la primera tarea la realiza std::vector::clear(). Pero, en general, debe leer los documentos para estar seguro. Como un ejemplo opuesto, Qt's QVectores más fácil de entender a este respecto, ya que su método para verificar el vacío es QVector::isEmpty().

— Ruslan

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

shouldComponentUpdate: (newProps: any) => boolean

— Acosar
fuente

debería ser, en mi opinión, un nombre bastante pobre, "bueno, debería cerrar el documento, pero en realidad no estoy muy seguro"

— Lovis

@lovis: Creo que el comentario de Harry es muy válido. Por ejemplo, podría delegar algunas acciones relacionadas con la base de datos a través de una capa de complemento, cada complemento tiene un método "ShouldCloseConnection" que informa al marco que se debe realizar una limpieza. Solo un ejemplo, pero "debería" es definitivamente un prefijo válido.

— Greg

@greg ¿Cómo es eso menos ambiguo que WillCloseConnection?

— Básico

@Lovis Generalmente usamos is...pero usamos should...en algunos nombres de argumentos de función, lugares donde el booleano indica a qué se supone que la función cambia las cosas . Si una función puede opcionalmente cerrar un documento, llamando al parámetro de control que isClosedsería preciso (que no está cerrado todavía ) y así podríamos utilizar shouldClosepara indicar que esto es lo que se supone que la función de hacer. (Ejemplo arbitrario; probablemente no tendríamos una función como esta, particularmente porque cerrar un documento debería ser lo suficientemente pesado como para tener una llamada dedicada.)

— KRyan

@Basic Al menos en nuestro caso, will...está reservado para funciones asincrónicas que devuelven una promesa; Si la función descrita en mi comentario anterior es síncrona, el uso will...sería inconsistente con nuestro nombre.

— KRyan