Est-il judicieux d'utiliser «ys» au lieu de «ies» dans les identificateurs pour faciliter la fonction de recherche et de remplacement? [fermé]

9

Bien que grammaticalement incorrect, lors de l'écriture d'identifiants pour des fonctions, des variables, etc., est-il logique d'ajouter simplement un "s" aux pluriels de mots se terminant par Y? Ma raison en est que si vous devez rechercher et remplacer, par exemple, en remplaçant "entreprise" par "fournisseur", "entreprise" correspondrait à la fois au singulier et au pluriel (" entreprise et" entreprise s "), alors que si le pluriel était correctement orthographié, vous devrez effectuer deux recherches distinctes.

SHNC
la source
8
Qu'en est-il des enfants, des souris, des couteaux, des loups, des hommes, des femmes, des épouses et des dents? Tout est valable pour éviter les "deux recherches séparées" tant redoutées .
Tulains Córdova
3
J'ai un faible pour les wolfys plutôt que pour les wolfies ...
Jimmy Hoffa
2
Envisagez-vous vraiment de renommer les identifiants très souvent dans votre flux de travail? Il semble un peu exagéré de prendre toute la folie cognitive des noms mal orthographiés dans le code juste pour prendre en charge une fonction qui pourrait ne jamais être utilisée.
Kent A.
10
Croyez-moi, vous ne voulez pas appliquer une opération de recherche et de remplacement sur une grande base de code pour un mot comme «entreprise» sans contrainte «de mots uniquement». Ainsi, vous devrez également utiliser deux recherches distinctes.
Doc Brown
2
Deux. Séparé. Recherches.
Tulains Córdova

Réponses:

24

Ces recherches et remplacements doivent être effectués avec soin et chaque modification doit être vérifiée manuellement, par exemple pour éviter que "accompagne" dans un commentaire ne devienne "fournisseur" avec le changement de votre société / fournisseur. En tant que tel, deux recherches distinctes pour «société» et «sociétés» ne devraient pas créer de frais généraux importants par rapport au temps passé à inspecter et à approuver chaque modification.

Ainsi, les mots mal orthographiés pour effectuer une seule recherche offrent les inconvénients d'avoir l'air mauvais et d'être plus difficiles à lire qu'il ne devrait l'être, sans offrir aucun avantage évident.

David Arno
la source
11
Et, avec l'amélioration des outils de refactoring, la recherche globale et le remplacement basés uniquement sur le texte deviennent le moyen le moins fiable pour renommer un identifiant.
Kent A.
Ce ne serait pas un problème en utilisant une recherche «mots entiers uniquement», comme mentionné par Doc Brown.
SHNC
6
@ user3047082, la recherche de mots entiers ne correspondrait pas non plus aux "sociétés", rendant toute la question plutôt inutile ...
David Arno
6

Je suppose que vous parlez de renommer les fichiers de code source. Avec les IDE d'aujourd'hui, cela devrait toujours être fait avec les outils de refactoring de l'IDE. Si votre IDE ne l'a pas, envisagez de passer à un autre IDE. La plupart des outils de refactoring IDE conservent également un historique de refactoring, vous donnant la possibilité de "défaire" rapidement si vous n'aimez pas les résultats du refactor. En utilisant la recherche / remplacement, il se peut que vous n'ayez pas la possibilité d'annuler l'ensemble des modifications (sauf si vous utilisez peut-être vos outils de contrôle de révision et revenez à la version précédemment validée). De plus, en utilisant des outils de refactorisation, vous êtes plus sûr de changer par inadvertance quelque chose que vous n'aviez pas l'intention de changer.

javabeano
la source
3
À quiconque a signalé cette réponse comme étant de faible qualité: bien qu'elle ne réponde pas strictement à la question posée, elle donne une vue d'ensemble de la raison pour laquelle on voudrait utiliser un tel schéma de dénomination et une meilleure façon d'accomplir la même tâche. J'ai voté "ça va" à la critique du drapeau et j'ai ajouté un vote positif.
Merci, @Snowman. C'est dans la nature humaine, dans une zone inconnue, de formuler une question en fonction de votre propre état d'esprit (inexpérimenté). Oui, même si je n'ai pas répondu à la vraie question, mon hypothèse de ce qui était réellement demandé était basée sur d'autres indices de la question. Les pluriels que j'ai rencontrés le plus proviennent d'outils de génération de code, par exemple, XSD-to-POJO, Hibernate / JPA reverse engineering à partir d'une base de données, etc. Essentiellement, si ces pluriels sont dans le code et que l'auteur n'a pas aimé le choix de pluriels, ils n'étaient probablement pas écrits par l'auteur et étaient plus susceptibles d'être générés automatiquement.
javabeano
-9

Oui! Oui! Oui! Il est parfaitement logique de le faire. Et je le fais depuis des années.

Divulgation 1: l'anglais n'est pas ma langue maternelle.

Divulgation 2: Ma connaissance de la grammaire anglaise est considérablement meilleure que celle du locuteur natif moyen.

Divulgation 3: Quand il s'agit de communiquer avec les humains, je suis une grammaire nazie véhémente.

Et maintenant que ces divulgations sont à l'écart, permettez-moi de dire que la grammaire anglaise n'a pas sa place dans le code. Vous voyez, c'est pourquoi cela s'appelle du code et non de la prose . Il est censé avoir une certaine ressemblance avec un langage compris par les humains, à des fins de lisibilité, mais à part cela, ce dont nous avons le plus besoin du code n'est pas les qualités de la prose; ce sont d'autres qualités plus techniques, comme la précision , la non- ambiguïté et la justesse . C'est pourquoi la syntaxe C de if( x != y ) y++;est bien préférable à la IF X IS NOT EQUAL TO Y THEN ADD 1 TO Y END-IF.syntaxe de Cobol. L'opportunité alléguée de compilateurs qui comprennent le langage naturel est une erreur, et ne me croyez pas sur parole, voyez ce qu'en dit Ol'Edsger:Edsger W. Dijkstra, Sur la folie de la "programmation en langage naturel" .

Une autre qualité qui est importante est la calculabilité des identifiants . Le fait qu'une propriété appelée Colorpuisse toujours être lue via une méthode appelée getColor()et écrite via une méthode appelée setColor()est d'une importance capitale. Ces identifiants sont calculables à partir du nom de la propriété, vous n'avez donc pas à les connaître par cœur. Si un programmeur devait choisir une paire de méthodes appelées getColor()d'une part, mais colorize()d'autre part, leurs collègues envisageraient à juste titre ce sabotage. Voilà à quel point la calculabilité des identifiants est importante.

De plus, des outils de programmation peuvent être écrits (et beaucoup d'entre eux ont en fait été écrits, par exemple, Hibernate ) qui peuvent calculer ces noms. Sans calcul des noms d'identifiants, vous devrez utiliser une syntaxe supplémentaire (par exemple dans Hibernate, des annotations supplémentaires) pour spécifier précisément à chaque outil comment créer chaque nom d'identifiant unique, ou précisément quel nom ad hoc vous avez donné à chaque entité.

Ainsi, la calculabilité des identifiants est importante, alors que dans le même temps la grammaire anglaise n'est pas pertinente, (puisque nous ne faisons pas de programmation en langage naturel), donc pour pouvoir calculer le nom d'une collection d'entités en ajoutant toujours "s" au nom d'un seul cas est parfaitement logique, sans parler du fait qu'il viole la sensibilité de la plupart des gens (y compris la mienne) à la langue anglaise.

Et que cela nous plaise ou non, telle est la tendance de l'avenir. La langue maternelle de la majorité des programmeurs de la planète n'est plus l'anglais, et la tendance est de continuer très fortement dans cette direction. (De plus, je ne serais même pas prêt à parier de l'argent sur la suggestion que l'anglais est la langue maternelle de la majorité des programmeurs travaillant aux États-Unis en ce moment.) Ce sont des gens qui, dans une large mesure, lorsqu'ils essaient de calculer le nom d'une collection à partir du nom d'une seule instance de "société", ajoutera simplement un "s", et la forme "sociétés" ne lui traversera même pas l'esprit. Pour un pourcentage important et toujours croissant de programmeurs dans le monde, la connaissance des particularités de la langue anglaise n'ajoute aucune valeur à leur travail, elle ne le rend que légèrement plus difficile.

Mike Nakis
la source
7
1. Les indices et les indices sont tous deux des pluriels valides d'index. Vous vous trompez en croyant qu'un seul est correct, par exemple, veuillez consulter oxforddictionaries.com/definition/english/index . 2. Un X privé, qui peut être lu via getX et écrit via via setX n'est pas privé; c'est une valeur publique. 3. Le code est un document de conception. Il informe un compilateur sur la façon de générer du "code machine", mais plus important encore, il décrit cette conception d'une manière que d'autres personnes peuvent facilement lire. La lisibilité est l'un des deux aspects les plus importants du code (la testabilité étant l'autre).
David Arno
3
Le code est écrit pour deux raisons: pour les humains à lire et pour les ordinateurs à exécuter. Certains diraient que le code source est écrit principalement pour être lu par les humains, car la majeure partie est immédiatement compilée en code octet avant que l'ordinateur ne l'exécute. Ainsi, alors que les ordinateurs ne se soucient pas de la bonne grammaire, les humains le font certainement.
Eric King
3
Bien que l'anglais ne soit pas votre langue maternelle, il se peut que ce soit la prochaine personne qui lise votre code. Cela confondra probablement aussi d'autres personnes de votre langue maternelle qui ont appris l'anglais.
Andy
2
ou vous ne ferez que blesser ceux qui doublent Companysquand cela devrait être Companies. Après tout, l'intérêt du code que nous écrivons habituellement est en fait de le rapprocher du langage naturel.
Andy
2
Quoi qu'il en soit, je trouve ce papier plein de merde. Le code est entre le langage naturel et le bytecode. Si ce n'est pour faciliter la compréhension humaine du code, il n'y aurait aucune raison de ne pas entrer directement le bytecode.
Andy