Dans mon équipe, nous travaillons en étroite collaboration avec quelques architectes logiciels. Ils approuvent toutes les décisions de conception de nos projets, font des revues de code, etc.
Nos projets consistent principalement en des fonctionnalités backend implémentées en PHP utilisant le framework Symfony 2. Donc, syntaxiquement, le code, les conventions de dénomination et la structure du projet semblent presque identiques à ce à quoi Java ressemblerait (Symfony 2 encourage une telle structure). Je le mentionne car les conventions spécifiques à Java s'appliquent également dans notre cas (si possible).
Récemment, ils ont suggéré quelque chose que je trouve très étrange: toutes les méthodes devraient avoir des conjonctions dans leur nom, par exemple getEntityOrNull
, setValueOrException
etc.
Une telle convention de dénomination me semble très mal, mais je ne peux pas trouver d'arguments concrets ou d'articles / pages en ligne qui contestent spécifiquement cela.
Les seules choses que j'ai trouvées sont:
- ces informations doivent être présentes dans les annotations de la méthode, comme
@return
ou@throws
- l'utilisation de conjonctions ("et", "ou" etc.) dans les noms de méthode suggère généralement que le principe de responsabilité unique n'est pas correctement respecté
Quels sont les autres arguments concrets contre cette convention de dénomination?
the use of conjunctions ("and", "or" etc.) in method names usually suggest that the Single Responsibility Principle is not properly respected
Ce n'est pas le cas pour les exemples que vous avez énumérés, où la conjonction est utilisée pour clarifier le mécanisme utilisé pour gérer les échecs, pas pour indiquer qu'il peut faire une chose ou une autre. Même la fonction la plus étroitement définie peut avoir des conditions d'échec légitimes, par exemple le saut d'une pile vide.
Int32.TryParse
et Int32.Parse
- les deux analysent une chaîne en un entier, mais le premier retourne un booléen indiquant le succès et le second renvoie en cas d'échec.
Try...
, ...OrNull
, ...OrDefault
. @EricLippert Ce n'est pas la seule convention en .net. Considérez Single
vs SingleOrDefault
, qui est très proche OrNull
du PO suggéré.