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 Color
puisse 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.