S'il y a une méthode

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

devrait-il plutôt s'appeler IsStuffDone()?

Les deux noms pourraient être mal interprétés par l'utilisateur: Si le nom est: DoStuff()pourquoi renvoie-t-il un booléen? Si le nom est, IsStuffDone()il n'est pas clair si la méthode exécute une tâche ou ne vérifie que son résultat.

Existe-t-il une convention pour ce cas? Ou une approche alternative, comme celle-ci est considérée comme imparfaite? Par exemple, dans les langages ayant des paramètres de sortie, tels que C #, une variable d'état booléen peut être transmise à la méthode sous la forme d'une variable et le type de résultat de la méthode doit être void.

EDIT: Dans mon problème particulier, la gestion des exceptions ne peut pas être directement déléguée à l'appelant, car la méthode fait partie d'une implémentation d'interface. Par conséquent, l'appelant ne peut pas être chargé de traiter toutes les exceptions d'implémentations différentes. Il ne connaît pas ces exceptions. Cependant, l'appelant peut gérer une exception personnalisée, comme StuffHasNotBeenDoneForSomeReasonExceptionsuggéré dans la réponse et le commentaire de npinti .

Dans .NET, vous avez souvent des paires de méthodes dans lesquelles l'une d'elles peut générer une exception ( DoStuff), l'autre renvoie un statut booléen et, en cas d'exécution réussie, le résultat réel via un paramètre out ( TryDoStuff).

(Microsoft appelle cela le "modèle d'analyse par essai" , car l'exemple le plus frappant est celui des TryParseméthodes de divers types primitifs.)

Si le Trypréfixe n'est pas courant dans votre langue, vous ne devriez probablement pas l'utiliser.

Et si vous jetiez simplement l'exception au code d'appel?

De cette façon, vous déléguez la gestion des exceptions à quiconque utilise votre code. Et si, dans le futur, vous voudriez faire ce qui suit:

• Si aucune exception n’est levée, passez à l’action A
• Si (par exemple) un FileNotFoundExceptionest lancé, passez à l'action B
• Si une autre exception est générée, passez à l'action C

Si vous rejetez votre exception, la modification ci-dessus impliquerait simplement l'ajout d'un catchbloc supplémentaire . Si vous le laissez tel quel, vous devrez modifier la méthode et l'emplacement à partir duquel la méthode est appelée, qui, selon la complexité du projet, peut se trouver à plusieurs emplacements.

DoStuff() est suffisant, et la valeur de retour de la fonction doit être documentée, et vous n'avez pas besoin de le mentionner dans le nom de la fonction, recherchez plusieurs 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, l' API Collection définit une méthode d'ajout qui renvoie un booléen. Il retourne essentiellement si add a changé la collection. Ainsi, pour un Listélément, il retourne généralement la valeur true, car l'élément a été ajouté, alors que pour un, Setil peut renvoyer la valeur false, si l'élément était déjà présent, car Sets autorise chaque élément unique au plus une fois.

Cela dit, si vous ajoutez un élément non autorisé par la collection, par exemple une valeur null, l’ajout jettera un NullPointerException plutôt que de renvoyer faux.

Lorsque vous appliquez la même logique à votre cas, pourquoi devez-vous renvoyer un booléen? S'il s'agit de cacher une exception, ne le faites pas. Il suffit de lancer l'exception. De cette façon, vous pouvez voir ce qui a mal tourné. Si vous avez besoin d'un booléen, parce que cela n'a peut-être pas été fait, pour une raison autre qu'une exception, nommez la méthode DoStuff(), car cela représente le comportement. Ça fait des trucs.

Pourrait échouer pour différentes raisons, exception, conditions normales, utiliserait donc ceci:

boolean doStuff() - returns true when successful

L'important est de documenter ce que le booléen signifie.

J'ai l'habitude de méthodes renvoyer un OperationResult(ou OperationResult<T>) et définir la IsSuccesspropriété sur le OperationResultapproprié. Si la méthode 'habituelle' est vide OperationResult, renvoyer , si la méthode 'habituelle' renvoie un objet, renvoyer OperationResult<T>et définir la Itempropriété de OperationResultmanière appropriée. Je suggère également d'avoir des méthodes OperationResulttelles que .Failed(string reason)et .Succeeded(T item). OperationResultdevient rapidement un type familier dans vos systèmes et les développeurs doivent savoir comment le gérer.

Cela dépend vraiment de la langue que vous utilisez. Comme pour certaines langues, il existe des conventions et des protocoles qui n'existent pas vraiment dans beaucoup de langues.

Par exemple, dans le langage Objective-C et dans le SDK iOS / Mac OS X, les noms de méthode sont généralement les suivants:

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

Comme vous pouvez le constater, il existe une méthode appelée viewDidLoad. Je préfère utiliser ce type de nommage chaque fois que je crée mes propres applications. Cela pourrait être utilisé pour vérifier si quelque chose était supposé se passer comme vous l'avez dit. Je pense que vous réfléchissez trop à ce que vous nommez vos méthodes. La plupart des méthodes renvoient le statut de ce qu'elles font, peu importe, prenez l'exemple suivant:

En PHP, mysql_connect () retournera false si la connexion échoue. Il ne dit pas qu'il le fera, mais il le fait et la documentation l'indique, de sorte qu'il ne puisse pas être mal interprété par le programmeur.

J'aimerais suggérer d'utiliser le préfixe "Essayer". Il s'agit d'un modèle bien connu pour les situations dans lesquelles la méthode peut réussir ou non. Ce modèle de dénomination a été utilisé par Microsoft dans .NET Framework (par exemple, TryParseInt).

Mais, peut-être que ce n'est pas à propos de nommer. Il s'agit de la façon dont vous concevez les paramètres d'entrée / sortie de votre méthode.

Mon idée est que si une méthode a une valeur de retour, l'appel de cette méthode devrait alors avoir pour but d'obtenir cette valeur de retour. Donc, vous devriez éviter d'utiliser le type de retour pour indiquer le statut d'une opération.

En C #, je préfère utiliser un paramètre out. En utilisant un out, je marque le paramètre comme paramètre latéral. Spécialement, ce C # 6 supportera la déclaration de variable inline.

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

Je choisirais un nom basé sur le rôle principal de la méthode. Le fait que cette méthode retourne une valeur booléenne ne requiert pas le préfixe 'Is'. Ayons du code Java, qui utilise le préfixe 'Is' assez souvent. Regarde java.io.File.delete(). Ça revient boolean, mais ça ne s'appelle pas isFileDeleted(). La raison en est que le rôle principal du métod est de supprimer un fichier. Quelqu'un appelle cette méthode avec l'intention de supprimer un fichier.

Le booléen est juste là pour communiquer le résultat du travail. Par contre voyons java.util.Map.isEmpty(). Évidemment, vous appelez une telle méthode pour savoir si la collection est vide. Vous ne voulez rien faire. Vous voulez juste savoir quel est l'état actuel.

Donc, personnellement, je resterais définitivement avec DoStuff().

C'est un problème très important pour moi. Souvent, lorsque je maintiens un code hérité, je tombe sur une méthode que j'appelle personnellement "méthode du mensonge". Le nom suggère l'action A, mais le corps effectue l'action B. L'exemple le plus intéressant est une méthode de lecture qui modifie les données de la base de données.