Si hay un método

bool DoStuff() {
    try {
        // doing stuff...
        return true;
    }
    catch (SomeSpecificException ex) {
        return false;
    }
}

¿debería ser llamado IsStuffDone()?

El usuario puede malinterpretar ambos nombres: si el nombre es DoStuff()por qué devuelve un valor booleano? Si el nombre es, IsStuffDone()no está claro si el método realiza una tarea o solo verifica su resultado.

¿Hay alguna convención para este caso? ¿O un enfoque alternativo, ya que este se considera defectuoso? Por ejemplo, en lenguajes que tienen parámetros de salida, como C #, una variable de estado booleana podría pasarse al método como uno y el tipo de retorno del método sería void.

EDITAR: en mi problema particular, el manejo de excepciones no se puede delegar directamente a la persona que llama, porque el método es parte de una implementación de interfaz. Por lo tanto, la persona que llama no puede ser acusada de ocuparse de todas las excepciones de diferentes implementaciones. No está familiarizado con esas excepciones. Sin embargo, la persona que llama puede lidiar con una excepción personalizada StuffHasNotBeenDoneForSomeReasonExceptioncomo se sugirió en la respuesta y comentario de npinti .

En .NET, a menudo tiene pares de métodos donde uno de ellos puede lanzar una excepción ( DoStuff), y el otro devuelve un estado booleano y, en una ejecución exitosa, el resultado real a través de un parámetro de salida ( TryDoStuff).

(Microsoft llama a esto el "Patrón Try-Parse" , ya que quizás el ejemplo más destacado para ello son los TryParsemétodos de varios tipos primitivos).

Si el Tryprefijo es poco común en su idioma, entonces probablemente no debería usarlo.

¿Qué pasa si simplemente lanzaste la excepción al código de llamada?

De esta manera, está delegando el manejo de excepciones a quien esté usando su código. ¿Qué pasa si en el futuro desea hacer lo siguiente?

• Si no se lanzan excepciones, tome la acción A
• Si (por ejemplo) FileNotFoundExceptionse lanza a, tome la acción B
• Si se produce alguna otra excepción, tome la acción C

Si rechaza su excepción, el cambio anterior simplemente implicaría la adición de un catchbloque adicional . Si lo deja como está, necesitaría cambiar el método y el lugar desde el que se llama el método, que, dependiendo de la complejidad del proyecto, puede estar en múltiples ubicaciones.

DoStuff() es suficiente, y el valor de retorno de la función debe documentarse, y no necesita mencionarlo en el nombre de la función, buscando muchas API disponibles:

PHP

// this method update and return the number affected rows 
// called update instead of updateAndGetAffectedCount
$affected = $query->update(/* values */);

C-Sharp

// Remove item from the List
// returns true if item is successfully removed; otherwise, false.
public bool Remove( T item )

En Java, la API de colección define un método de agregar que devuelve un valor booleano. Básicamente, devuelve si el complemento cambió la colección. Entonces, para un List, generalmente devolverá verdadero, ya que el elemento se agregó, mientras que para un Setpodría devolver falso, si el elemento ya estaba allí, ya que Sets permite cada elemento único como máximo una vez.

Dicho esto, si agrega un elemento que no está permitido por la colección, por ejemplo, un valor nulo, el complemento arrojará un valor NullPointerExceptionfalso en lugar de devolverlo.

Cuando aplica la misma lógica a su caso, ¿por qué necesita devolver un valor booleano? Si es para ocultar una excepción, no lo hagas. Solo lanza la excepción. De esa manera puedes ver lo que salió mal. Si necesita un valor booleano, ya que podría no haberse hecho, por alguna otra razón que no sea una excepción, asigne un nombre al método DoStuff(), ya que representa el comportamiento. Hace cosas

Podría fallar por diferentes razones, excepción, condiciones normales, así que usaría esto:

boolean doStuff() - returns true when successful

Importante es documentar lo que significa el booleano.

Por lo general, los métodos devuelven un OperationResult(o OperationResult<T>) y establecen la IsSuccesspropiedad en el OperationResultapropiado. Si el método 'usual' es nulo, devuelva OperationResult, si el método 'usual' devuelve un objeto, devuelva OperationResult<T>y establezca la Itempropiedad en el OperationResultapropiado. También sugeriría tener métodos en OperationResultcomo .Failed(string reason)y .Succeeded(T item). OperationResultrápidamente se convierte en un tipo familiar en sus sistemas y los desarrolladores saben cómo manejarlo.

Realmente depende del idioma que estés usando. Al igual que para algunos idiomas, existen convenciones y protocolos que realmente no existen en muchos idiomas o en ninguno.

Por ejemplo, en el lenguaje Objective-C y los nombres de métodos SDK de iOS / Mac OS X generalmente van en la línea de:

- (returndatatype) viewDidLoad {
- (returndatatype) isVisible {
- (returndatatype) appendMessage:datatype variablename with:datatype variablename {

Como puede ver, hay un método llamado viewDidLoad. Prefiero usar este tipo de nombres cada vez que hago mis propias aplicaciones. Esto podría usarse para verificar si se suponía que algo iba a suceder como usted dijo. Creo que estás pensando demasiado en lo que nombras tus métodos. La mayoría de los métodos devuelven el estado de lo que hacen independientemente, tome el ejemplo:

En PHP, mysql_connect () devolverá falso si la conexión falla. No dice que lo hará, pero lo hace y la documentación dice que sí, por lo que no se puede malinterpretar al programador.

Me gustaría sugerir utilizar el prefijo 'Probar'. Este es un patrón bien conocido para situaciones en las que el método puede tener éxito o no. Este patrón de nombres ha sido utilizado por Microsoft en .NET Framework (por ejemplo, TryParseInt).

Pero, tal vez no se trata de nombrar. Se trata de cómo diseñar los parámetros de entrada / salida de su método.

Mi idea es que si un método tiene un valor de retorno, entonces el propósito de llamar a ese método debería ser obtener ese valor de retorno. Por lo tanto, debe evitar usar el tipo de retorno para indicar el estado de una operación.

En C #, prefiero usar un parámetro out. Usando una salida, estoy marcando el parámetro como un parámetro lateral. Especialmente que C # 6 admitirá la declaración de variable en línea.

DoStuff(out var isStuffDone); // The out parameter name clearly states its purpose.
DoStuff(out var _); // I use _ for naming parameters that I am ignoring.

Elegiría un nombre basado en la función principal del método. El hecho de que ese método devuelva un valor booleano no exige el prefijo 'Is'. Tengamos un código Java, que usa el prefijo 'Is' de forma bastante extensa. Echa un vistazo java.io.File.delete(). Regresa boolean, pero no se llama isFileDeleted(). La razón es que la función principal del método es eliminar un archivo. Alguien llama a este método con la intención de eliminar un archivo.

Lo booleano está ahí solo para comunicar el resultado del trabajo. Por otro lado, veamos java.util.Map.isEmpty(). Obviamente, llama a dicho método para averiguar si la colección está vacía. No quieres que se haga nada. Solo quiere saber cuál es el estado actual.

Así que personalmente, definitivamente me quedaría con DoStuff().

Este es un tema muy importante para mí. Muchas veces, cuando mantengo el código heredado, me encuentro con algo que personalmente llamo "método de mentira". El nombre sugiere la acción A, pero el cuerpo realiza la acción B. El ejemplo más extraño es un método getter que cambia los datos en la base de datos.