un programmeur, plusieurs langues - le dilemme du nom

Lorsque vous travaillez sur plusieurs langages de programmation, vous rencontrez un problème ...

Un nom (identifiant) valide dans une langue n'est pas valide dans une autre. Par exemple...

var new function thissont des mots clés en JavaScript, mais vous pouvez les utiliser librement en Python. De même list dict defpeut être utilisé en JavaScript sans problèmes.

Ceci est très courant et quelque chose que les programmeurs se familiarisent généralement rapidement lorsqu'ils programment dans plusieurs langues.

Cependant, lorsque vous travaillez en collaboration, vous devez définir certaines règles / directives pour les membres de votre équipe afin d'assurer la cohérence et l'uniformité du code. Avec les équipes, ce problème devient plus important que de simplement se rappeler ce qui est valide et ce qui ne l'est pas pendant que vous programmez.

Donc, ma question est, quelles stratégies vous adoptez ...

• prenez simplement une union de tous les mots réservés présents dans toutes les langues que vous utilisez, distribuez une liste à tout le monde et abstenez-vous de les utiliser?
• accepter la diversité et faire plus d'efforts lors du "changement de contexte"
• adopter un terrain intermédiaire où une langue peut utiliser l'autre, mais pas l'inverse

(Remarque: je ne parle que de Python et JavaScript dans cette question ... mais veuillez répondre à la question plus largement)

-- MISE À JOUR --

Merci pour toutes les réponses. Donc, le consensus général que je vois émerger est de laisser les programmeurs utiliser n'importe quel nom indépendamment de ce qu'ils font dans d'autres langues - tant que les noms sont descriptifs, cela ne fait pas de mal.

Ayant programmé dans un certain nombre de langues au cours des 30+ années de mon expérience, je dirais qu'essayer de trouver des normes de dénomination qui fonctionneront dans n'importe quelle langue est probablement une idée du ciel.

Au début de mon expérience, j'ai essayé d'utiliser les macros #define en C pour créer des choses qui feraient ressembler mon code C au code Pascal que j'utilisais auparavant. J'étais tellement habitué à la programmation en Pascal que je me suis dit que si je pouvais simplement faire fonctionner C comme Pascal, cela me rendrait plus productif. J'ai vite découvert que j'avais tort.

Ce qui m'a rendu plus productif, c'est d'apprendre le C et de ne pas essayer d'utiliser la syntaxe Pascal dans un autre langage simplement parce que cela m'a rendu plus confortable.

Je pense que vous contraindrez potentiellement vos programmeurs en les empêchant de faire quelque chose dans une langue, simplement parce que c'est mal de le faire dans une autre langue que vous utilisez.

Si vous limitez vos conventions de dénomination aux choses qui ont du sens pour expliquer l'utilisation des variables, vous créerez probablement un bon code, dans n'importe quelle langue.

Vous ne devriez pas nommer les choses "liste", "nouveau", "var", "ceci" en premier lieu, car elles ne sont suffisamment descriptives dans aucune langue.

Passer de, disons, javascript à python est déjà un changement de contexte. Je ne pense pas que ce soit mauvais si les noms de variables changent, surtout si les changements de nom sont idiomatiques avec la langue. On pourrait même affirmer que des changements de contexte plus difficiles peuvent aider dans ce cas, car cela contribue à renforcer "mec, vous écrivez javascript pas python maintenant."

Je pense que si vous utilisez une variable descriptive nommant le problème que vous décrivez devrait être minime. Cela dit, s'il est minime, accepter le changement de contexte provoqué par la dénomination des variables entre les langues devient également minime.

La plupart des mots réservés (dans n'importe quelle langue) sont assez généraux. Je préfère les noms de variable / fonction qui sont plus descriptifs et cela signifie que je ne rencontre presque jamais ce problème. Je dois admettre avoir été infecté par Charles Simonyi avec son schéma de nommage d'origine - c'était à Xerox à la fin des années 70, avant même qu'il s'appelle la notation hongroise - et cela tend également à signifier que les noms sont quelque chose qu'aucun humain sain d'esprit utiliserait jamais comme mots réservés.

Vous ne devriez pas perdre votre temps à rédiger des lignes directrices avant de découvrir qu'il s'agit d'un problème réel et non hypothétique.

Une situation à laquelle je peux penser où cela peut devenir un problème est lorsque vous partagez des structures de données entre des langages de programmation. Par exemple, si vous avez un objet Javascript côté client qui se reflète dans un objet Python côté serveur et que vous souhaitez naturellement qu'ils aient le même nom pour leurs membres. Dans ce cas, la règle est simple: n'utilisez pas de noms réservés dans l'une des langues. C'est ça. Écrivez cela dans les directives si vous le souhaitez. Passez maintenant à des tâches plus importantes.

BTW, ni list ni dict n'est un mot réservé en Python. Ils peuvent être utilisés en tant que noms de variables, bien que ceux-ci sont assez moche.

D'après mon expérience, le correctif est d'avoir de larges conventions de nommage qui s'appliquent à toutes les langues. Que ce soit JavaScript, C # ou un autre langage génial, la façon dont les variables et les classes sont nommées peut devenir un standard dans une base de code, ce qui est généralement la façon dont je verrais la résolution de ce problème. Les conventions peuvent être convenues par consensus de tout le monde, simplement une majorité voulant une ligne directrice, la direction disant: «Voici comment nous procédons» ou quelques autres possibilités que j'imagine.

Je vois rarement le problème d'identification que vous décrivez, car la plupart du temps, mon nom de classe ou de variable est suffisamment descriptif pour ne pas entrer en conflit si facilement. Dans le même temps, si l'on travaille avec d'autres que d'avoir une clarté sur la façon dont l'équipe veut gérer c'est le point important.

Je ne vois pas comment cela pourrait être un problème, à moins que vous ne prévoyiez de déplacer du code d'une langue à une autre. Si vous avez personnellement tendance à oublier quels noms de variables sont valides, n'utilisez pas de nom de variable à moins que vous ne soyez personnellement sûr qu'il est valide. Mais si d'autres personnes utilisent des noms de variables invalides, leur code ne se compilera pas ou ne s'exécutera pas. Donc, si vous travaillez sur le code de quelqu'un d'autre et qu'il a appelé quelque chose de 'var', vous pouvez être sûr que c'est un nom valide dans la langue qu'il utilise.

Si vous prévoyez de déplacer du code d'une langue à une autre, vous aurez peut-être besoin d'une liste de noms interdits. Par exemple, mon document sur les pratiques de codage C interdit d'utiliser new ou class comme variable car cela rend le code plus difficile à porter en C ++. Dans ce cas, il est raisonnable de définir des règles qui facilitent ce travail, si cela devenait nécessaire,

Il suffit de s'en tenir à CamelCase en minuscules. Ça marche partout. C'est ce qu'on appelle la recherche du plus petit dénominateur commun entre les systèmes incompatibles, et vous vous retrouverez à le faire souvent!