Question

C # et Java autorisent presque tous les caractères dans les noms de classe, les noms de méthodes, les variables locales, etc. Il est déconseillé d’utiliser des caractères non-ASCII. à lire, ou l’arrogance américaine est-elle le seul argument contre?

Était-ce utile?

La solution

Je voudrais m'en tenir à l'anglais, tout simplement parce que vous ne savez généralement pas qui travaille sur ce code, et que certains outils tiers utilisés dans la progression de la construction, des tests et des anomalies peuvent poser problème. Dactylographie & # 228; & # 246; & # 252; & # 223; sur un clavier non allemand est simplement un PITA, et je crois simplement que toute personne impliquée dans le développement de logiciels devrait parler anglais, mais peut-être que ce n’est que mon arrogance en tant que locuteur non anglophone.

Ce que vous appelez "arrogance américaine" Ce n’est pas si votre programme utilise ou non des noms de variables internationaux, c’est quand votre programme pense "W & # 228; hrung". et " Wahrung " sont les mêmes mots.

Autres conseils

Je dirais que cela dépend entièrement de qui travaille sur la base de code.

Si vous avez un petit groupe de développeurs qui partagent tous un langage commun et que vous ne prévoyez jamais de faire appel à des personnes qui ne parlent pas la langue pour travailler sur le code, utilisez les caractères de votre choix.

Si vous avez besoin que des personnes de cultures et de langues différentes travaillent sur le code, il est probablement préférable de rester avec l'anglais, car c'est le dénominateur commun pour à peu près tout le monde dans le monde.

Si votre entreprise ne parle pas anglais et si vous pensez que Domain Driven Design a quelque chose à y voir, il y a un autre aspect: comment utilisons-nous, en tant que développeurs, la même langue de domaine que notre entreprise sans aucun coût de traduction? / p>

Cela ne signifie pas seulement des traductions entre les langues, par exemple anglais et norvégien, mais également entre des mots différents. Nous devrions utiliser exactement les mêmes mots que notre entreprise pour nos classes d'entités et nos services.

J'ai trouvé plus facile d'abandonner et d'utiliser ma langue maternelle. Maintenant que mon code utilise les mêmes mots, il est plus facile d'avoir une conversation avec mes experts de domaine. Et après un certain temps, vous vous y habituez, comme si vous aviez l'habitude de coder sans notation hongroise.

J'avais l'habitude de travailler dans une équipe de développement qui essuyait joyeusement leurs culs avec toutes les conventions de nommage (et d'ailleurs tout autre code). Croyez-le ou non, le fait de devoir composer avec les codes "# 228" et "246" du code a contribué à ma démission. Bien que je sois finlandais, je préfère écrire du code avec les paramètres du clavier américain, car les accolades et les accolades sont pénibles à écrire dans un clavier finlandais (essayez les touches alt et 7 et 0 pour les curlies).

Alors je dis bâton avec les caractères ascii.

Voici un exemple de ce que j'ai utilisé Identifiants non-ASCII, parce que je l’ai trouvé plus lisible que de remplacer les lettres grecques par leurs noms anglais. Même si je n'ai pas & # 952; ou & # 966; sur mon clavier (je me suis appuyé sur copier-coller.)

Cependant, toutes ces variables sont locales. Je garderais les identifiants non-ASCII en dehors des interfaces publiques.

Cela dépend:

  • Votre équipe se conforme-t-elle aux normes existantes nécessitant votre utilisation d'ASCII?
  • Votre code sera-t-il un jour réutilisé ou lu par quelqu'un qui ne parle pas votre langue maternelle?
  • Envisagez-vous un scénario dans lequel vous aurez besoin de demander de l'aide en ligne et ne pourrez donc pas copier-coller votre exemple de code dans son état actuel?
  • Êtes-vous certain que votre suite d'outils prend en charge le codage de code?

Si vous avez répondu «oui» à l’une des questions ci-dessus, restez uniquement en ASCII. Sinon, avancez à vos risques et périls.

SI vous avez dépassé les autres conditions préalables , vous avoir un extra (IMHO plus important) un - Quelle est la difficulté à taper le symbole.

Sur mon clavier anglais habituel, la seule façon dont je connaisse la lettre ç est de maintenir alt et de frapper 0227 sur le pavé numérique, ou de copier-coller.

Ce serait un énorme barrage routier dans la façon de taper rapidement. Vous ne voulez pas ralentir votre codage avec des choses aussi triviales si vous n'y êtes pas obligé. Les claviers internationaux peuvent atténuer ce problème, mais que se passe-t-il si vous devez coder sur votre ordinateur portable qui n’a pas de clavier international, etc.?

Une partie du problème vient du fait que le langage Java / C # et ses bibliothèques sont basés sur des mots anglais tels que if et toString () . Personnellement, je ne voudrais pas basculer entre une langue autre que l’anglais et l’anglais tout en lisant du code.

Toutefois, si votre base de données, votre interface utilisateur, vos logiques métier (y compris les métaphores) sont déjà dans une langue autre que l'anglais, il n'est pas nécessaire de traduire tous les noms de méthodes et variables en anglais.

Je voudrais m'en tenir aux caractères ASCII, car si votre équipe de développement utilise un SDK prenant uniquement en charge l'ASCII ou si vous souhaitez rendre votre code open source, de nombreux problèmes peuvent survenir. Personnellement, je ne le ferais pas même si vous n’avez pas l’intention de faire venir quelqu'un qui ne parle pas la langue dans le projet, car vous dirigez une entreprise et il me semble que celui qui dirige une entreprise souhaiterait que son entreprise se développe qui, à notre époque, signifie transcender les frontières nationales. Mon opinion est que l'anglais est la langue du royaume, et même si vous nommez vos variables dans une autre langue, il est inutile d'utiliser des caractères non-ASCII dans votre programmation. Si vous gérez des données au format UTF8, laissez à la langue le soin de le gérer: le programme de mon iPhone (qui implique des tonnes de données utilisateur entre le téléphone et le serveur) prend en charge UTF8, mais n'a pas d'UTF8 dans le code source . Il semble simplement ouvrir une boîte de conserve aussi grande sans presque en tirer profit.

L’utilisation de caractères non-ASCII est un autre casse-tête, même si elle ne mord probablement que dans des cas obscurs. Les caractères autorisés sont définis . en termes de méthodes Caractère. isJavaIdentifierStart (int) et Character.isJavaIdentifierPart (int) , définis en termes d'Unicode. Toutefois, la version exacte de Unicode utilisée dépend de la version de la plate-forme Java, comme indiqué dans la documentation de java.lang.Character .

Étant donné que les propriétés des caractères changent légèrement d'une version Unicode à l'autre, il est possible (mais probablement très peu probable) que vous ayez des identificateurs valides dans une version de Java, mais pas dans la suivante.

Comme cela a déjà été souligné, à moins que les noms de méthodes ne correspondent généralement à la langue, il est un peu étrange de changer constamment de langue pendant la lecture.

Pour les langues scandinaves & amp; En allemand, pour lequel je peux parler et donc parler, je recommanderais au moins d’utiliser des substitutions standard, c’est-à-dire.

ä / æ - > ae, ö / ø - > oe, å - > aa, ü - > ue

etc. juste au cas où d’autres pourraient trouver difficile de taper les lettres originales sans modifications du clavier ou du clavier. Pensez si vous deviez soudainement travailler avec une base de code où les développeurs utilisaient une troisième langue (par exemple, le français ç) et ne le faisaient pas. Passer de plus de deux keymaps pour taper efficacement serait pénible, selon mon expérience.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top