«A», «an» et «the» dans les noms de méthode et de fonction: quelle est votre opinion? [fermé]

16

Je suis sûr que beaucoup d'entre nous ont vu des noms de méthode comme celui-ci à un moment ou à un autre:

  • UploadTheFileToTheServerPlease
  • CreateATemporaryFile
  • WriteTheRecordToTheDatabase
  • ResetTheSystemClock

Autrement dit, les noms de méthode qui sont également des phrases en anglais grammaticalement correctes, et qui incluent des mots supplémentaires uniquement pour les faire lire comme de la prose. Personnellement, je ne suis pas un grand fan de ces noms de méthodes "littéraux", et je préfère être succint, tout en étant aussi clair que possible. Pour moi, des mots comme "a", "an" et "the" semblent tout simplement maladroits dans les noms de méthode, et cela rend les noms de méthode inutilement longs sans vraiment ajouter quoi que ce soit d'utile. Je préférerais les noms de méthode suivants pour les exemples précédents:

  • UploadFileToServer
  • CreateTemporaryFile
  • WriteOutRecord
  • ResetSystemClock

D'après mon expérience, c'est beaucoup plus courant que l'autre approche consistant à écrire les noms plus longs, mais j'ai vu les deux styles et j'étais curieux de voir ce que les autres pensaient de ces deux approches.

Alors, êtes-vous dans le camp des "noms de méthode qui se lisent comme de la prose" ou dans les "noms de méthode qui disent ce que je veux dire mais lus à haute voix comme un mauvais camp de traduction d'une langue étrangère vers l'anglais"?

Mike Spross
la source
7
Je n'ai jamais vu de méthodes avec des noms comme WriteTheRecordToTheDatabase. Si quelqu'un vérifiait cela, il serait sérieusement questionné.
Tim Robinson du
13
" Please"? Wow
configurateur
3
Je voudrais juste ajouter que wordpress a des fonctions d'assistance de modèle comme "the_contents ()", "get_the_post ()", etc. Cela me dérange énormément.
Carson Myers
1
@Carson Myers Hah, c'est un parfait exemple du monde réel. Je dois avoir supprimé les souvenirs de la dernière fois que j'ai regardé le code WordPress :-)
Mike Spross

Réponses:

21

Je conviens que les méthodes de prose sont nulles à une exception près:

Cas de tests unitaires

Ceux-ci ne sont généralement jamais appelés dans votre code et apparaissent dans les rapports de test. En tant que tel, il est pratique d'avoir des lectures avec un peu plus de prose:

  • AddingACustomerOrderFailWhenCustomersIdIsInvalid: Échec
  • OutOfBoundsPriceReturnsAnError: Passed
  • CanDeleteAnEventFromASeason: réussi

Même cela devrait être fait avec parcimonie, mais je peux le voir comme au moins un cas où des ajouts grammaticaux peuvent rendre un peu plus facile l'expression de ce qui a réussi et de ce qui a échoué. C'est, bien sûr, à moins que votre langage / framework ne fournisse un bon mécanisme pour les descriptions de test dans la lecture de test autre que les noms de méthode, auquel cas ignorez également celui-ci.

Fishtoaster
la source
1
+1 pour un bon exemple de cas où les noms de méthode en prose peuvent être réellement bénéfiques. C'est drôle, parce que maintenant que vous le mentionnez, je l' ai fait spécifiquement lors de l'écriture des noms des tests unitaires, et donc je savais ce que le test faisait quand je les ai exécutés plus tard.
Mike Spross
C'est utile et s'inscrit dans la MethodUnderTest_Condition_ExpectedBehaviour convention de dénomination des tests unitaires suggérée par Roy Osherove . par exemple AddOrder_WithInvalidCustomerId_Fails, CreateItem_WithOutOfBoundsPrice_ReturnsErroretDeleteEvent_EventExistsInSeason_Succeeds
StuperUser
@StuperUser pour le comportement attendu, vous avez en fait mis le résultat de test attendu et donc je n'ai aucune idée de ce que la méthode est censée retourner.
ediblecode
@danRhul Bon point, je n'étais pas assez clair; .._AdditionFailset .._DeletionSucceedsdevrait être mieux. J'ai mis le résultat de la méthode, mais comme vous le faites remarquer, ils pourraient être confondus avec les tests de terminologie de réussite / échec.
StuperUser
10

Pour paraphraser Lawrence de l'espace de bureau ...

Non.

GrandmasterB
la source
10

Ces noms «longs» ne sonnent pas comme de la prose . Lorsqu'ils sont seuls, peut-être, mais accompagnés du reste du code, ils ne font que gâcher davantage. Vérifiez-le:

bool ResultOfTheUpload
      = UploadTheFileToTheServerPlease(TheNameOfTheFile, TheServersAddress);

Yuuuuk! ..

Ce n'est pas un texte anglais valide, et dans aucun langage de programmation il ne ressemblera à un. Il n'y a donc aucun sens à dépenser des octets en articles.

P Shved
la source
1
Un bon exemple de pourquoi je n'aime pas tellement cette approche! Quand j'ai écrit la question, je me concentrais uniquement sur les noms de méthode ressemblant à de la prose, mais je suis d'accord avec vous: il est assez difficile de faire en sorte que le code appelant se lise comme de la prose, donc inutile de faire sonner les noms de fonctions individuelles comme écrites Anglais.
Mike Spross
3
Je suggèrebool ResultOfTheGentlyUploadOfTheFileToTheServer
Wizard79
J'ai travaillé avec une personne qui a créé des normes d'entreprise où «la variable» et «une méthode» devaient être suivies. Cette même personne aimait également avoir toutes les lignes de code alignées verticalement.
Chris
7

Du point de vue des programmeurs, "UploadFileToServer" est plus logique et plus facile à lire et à comprendre que "UploadTheFileToTheServerPlease".

Plus que la grammaire anglaise, la lisibilité et la compréhensibilité comptent plus dans la programmation!

Gopi
la source
Tout à fait d'accord .. si j'ai lu le code écrit en premier style pendant quelques jours, je suis sûr que cela me rendra fou ..
Naveen
@Naveen: J'ai travaillé avec du code comme celui-ci, et la première fois que j'ai eu, j'ai renommé toutes ces méthodes. Et je ne sais pas si c'était le développeur ou non, mais je pense qu'il ya une tendance à faire des fonctions multiples font les choses lorsque vous les écrivez en phrases, à savoir UploadTheFileAndProcessItAndEmailTheOrdersToTheCustomers, bien que je l' espère rien tout à fait mal que ça dans la vie réelle.
Mike Spross
@Mike Ensuite, je remanierais la méthode en 2 méthodes différentes;)
Gopi
2

Étant donné le nombre de fautes de frappe dans ma vie, je me retrouverais avec

* UploadTehFileToTehServerPleaz
* WriteTehRecordToTehDatabase
* ResetTehSystemClock
* ICanHazTehCheezburger

Sérieusement, je regarderais même le nom de ma classe. Si ma classe s'appelait "File", j'irais probablement avec

*UploadToServer
*DownloadFromServer

Ce serait donc

   File file = new file;
   file.UploadtoServer(ServerAddress);

Juste un exemple trivial, mais j'espère que c'est assez illustratif.

MIA
la source
Hehe. J'ai en fait vu "Teh" se glisser dans les noms de méthodes suivant le modèle de nommage "à l'anglaise". Quant à votre deuxième point: je suis tout à fait d'accord, la redondance dans les noms de méthodes est une autre bête noire ( File.UploadFileToServer... ugh).
Mike Spross
0

Personnellement, je m'en fiche. Je les ai vus et ils ne me dérangent pas. Je n'ai même pas pensé à eux jusqu'à ce qu'un autre programmeur se soit moqué d'eux. J'ai trouvé choquant que quelqu'un se soucie tellement de quelque chose qui compte si peu. Je veux dire qu'il était en colère contre ça. Mais c'était au début de ma carrière, il y a environ 11 ans, et depuis lors, j'ai constaté que les développeurs en colère pour des choses mineures sont en fait assez courants. C'est pourquoi les gestionnaires de développeurs sont si bien payés. Ils doivent traiter avec les développeurs au quotidien.

Et je préfère voir ça que "UL_FlToSrv".

ElGringoGrande
la source