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

16

Fermé . Cette question est basée sur l'opinion . Il n'accepte pas actuellement de réponses.

Vous souhaitez améliorer cette question? Mettez à jour la question afin d'y répondre avec des faits et des citations en modifiant ce message .

Fermé il y a 5 ans .

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"?

coding-style naming

— Mike Spross
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

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
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
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
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
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
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
source