Quelles sont les expériences d'utilisation d'unicode dans les identifiants

Question

Ces jours-ci, davantage de langues utilisent l’unicode, ce qui est une bonne chose. Mais cela présente aussi un danger. Dans le passé, il y avait des problèmes pour distinguer entre 1 et 1 et 0 et 0. Mais nous avons maintenant une toute nouvelle gamme de caractères similaires.

Par exemple:

ì, î, ï, ı, ι, ί, ׀ ,أ ,آ, ỉ, ﺃ

Avec ceux-ci, il n’est pas si difficile de créer des bugs très difficiles à trouver.

Dans mon travail, nous avons décidé de conserver les caractères ANSI pour les identificateurs. Quelqu'un utilise-t-il des identificateurs Unicode et quelles sont les expériences?

Answer 1

Outre les bogues de caractère similaires que vous avez mentionnés et les problèmes techniques pouvant survenir lors de l'utilisation d'éditeurs différents (w / BOM, wo / BOM, différents encodages dans le même fichier par copier-coller ne posent un problème que lorsqu'il existe en réalité des caractères ne peut pas être encodé en ASCII, etc.), j'estime qu'il ne vaut pas la peine d'utiliser des caractères Unicode dans les identificateurs. L'anglais est devenu la lingua franca du développement et vous devez vous en tenir à l'écriture de code.

Je trouve cela particulièrement vrai pour le code pouvant être vu n'importe où dans le monde par n'importe quel développeur (source ouverte ou code vendu avec le produit).

Answer 2

Mon expérience de l'utilisation de l'unicode dans les fichiers source C # était désastreuse, même si elle était japonaise (il n'y avait donc rien à confondre avec un "i"). Source Safe n’aime pas l’unicode et lorsque vous corrigez manuellement des fichiers sources corrompus dans Word, vous savez que quelque chose ne va pas.

Je pense que votre politique ANSI uniquement est excellente. Je ne vois vraiment aucune raison pour que cela ne soit pas viable (tant que la plupart de vos développeurs sont anglais, et même s'ils ne sont pas, le monde est habitué au jeu de caractères ANSI).

Answer 3

Je pense que ce n'est pas une bonne idée d'utiliser tout le jeu de caractères ANSI pour les identificateurs. Quelle que soit la page de code ANSI dans laquelle vous travaillez, votre page de code ANSI comprend des caractères que certaines autres pages de code ANSI n'incluent pas. Je vous recommande donc de vous en tenir à l'ASCII, pas de code de caractère supérieur à 127.

Lors d’expériences, j’ai utilisé une gamme de caractères ANSI plus large que le simple ASCII, même dans les identificateurs. Certains compilateurs l'ont accepté. Certains IDE nécessitaient que des options soient définies pour les polices pouvant afficher les caractères. Mais je ne le recommande pas pour une utilisation pratique.

Passons maintenant à la différence entre les pages de code ANSI et Unicode.

Lors d’expériences, j’ai stocké des fichiers source au format Unicode et utilisé des caractères Unicode dans des identificateurs. Certains compilateurs l'ont accepté. Mais je ne le recommande toujours pas pour une utilisation pratique.

Parfois, j'ai stocké des fichiers source au format Unicode et utilisé des séquences d'échappement dans certaines chaînes pour représenter les valeurs de caractères Unicode. C'est une pratique importante et je le recommande vivement. Je devais le faire surtout lorsque d'autres programmeurs utilisaient des caractères ANSI dans leurs chaînes et que leurs pages de code ANSI étaient différentes des autres pages de code ANSI. Les chaînes étaient donc corrompues et provoquaient des erreurs de compilation ou des résultats défectueux. Pour résoudre ce problème, utilisez des séquences d'échappement Unicode.

Answer 4

Je recommanderais également l’utilisation de l’ascii comme identifiant. Les commentaires peuvent rester dans une langue autre que l'anglais si l'éditeur / ide / le compilateur, etc. sont tous conscients des paramètres régionaux et configurés pour utiliser le même encodage.

De plus, certaines langues insensibles à la casse modifient les identifiants en minuscules avant de les utiliser, ce qui pose problème si les paramètres régionaux du système actif sont le turc ou l’azerbaïdjanais. voir ici pour plus d'informations sur le problème des paramètres régionaux turcs . Je sais que PHP le fait, et il a un bogue de longue date .

Ce problème est également présent dans tout logiciel comparant des chaînes utilisant des paramètres régionaux turcs, pas seulement les implémentations linguistiques, mais simplement pour les signaler. Cela provoque de nombreux maux de tête

.

Answer 5

Cela dépend de la langue que vous utilisez. En Python, par exemple, il m'est plus facile de rester en mode Unicode, car mes applications doivent fonctionner dans plusieurs langues. Ainsi, lorsque je reçois un fichier de quelqu'un (quelque chose) que je ne connais pas, j'assume Latin-1 et traduis en Unicode.

Fonctionne pour moi car je suis en Amérique latine.

En fait, une fois que tout est réglé, le tout devient une course en douceur.

Bien sûr, cela dépend de la langue de votre choix.

Answer 6

Je n'ai jamais utilisé Unicode pour les noms d'identifiant. Mais ce qui me vient à l’esprit, c’est que Python autorise les identifiants Unicode dans la version 3: PEP 3131 .

Forteresse est un autre langage qui utilise beaucoup de Unicode.

Même si vous décidez de ne pas utiliser Unicode, le problème refait surface lorsque vous utilisez une bibliothèque qui le fait. Vous devez donc vivre avec cela dans une certaine mesure.