一人のプログラマー、多くの言語—名前のジレンマ

複数のプログラミング言語にまたがって作業すると、問題が発生します...

ある言語の有効な名前（識別子）は、別の言語では無効です。例えば...

var new function thisJavaScriptのキーワードですが、Pythonで自由に使用できます。同様にlist dict def、JavaScriptで問題なく使用できます。

これは非常に一般的であり、プログラマーが複数の言語でプログラムを作成するときに一般的にすぐになじむものです。

ただし、コラボレーションで作業しているときは、コードの一貫性と均一性を確保するために、チームメンバーのいくつかのルール/ガイドラインをレイアウトする必要があります。チームでは、この問題は、プログラム中に有効なものとそうでないものを単に覚えるよりも重要になります。

だから、私の質問は、あなたが採用する戦略です...

• 使用するすべての言語に存在するすべての予約語の和集合を取り、すべての人にリストを配ってその使用を控えますか？
• 「コンテキストスイッチング」の際に多様性を受け入れ、さらに苦労する
• ある言語が他の言語を使用できるが、その逆は使用できない中間基盤を採用する

（注：この質問ではPythonとJavaScriptについてのみ話しますが、より広く質問に答えてください）

-更新-

すべての答えをありがとう。だから、私が浮上していると思う一般的なコンセンサスは、プログラマーが他の言語をどうするかに関係なく、どのような名前でも使用できるようにすることです。

私の30年以上の経験でかなりの数の言語でプログラミングを行ってきたので、どの言語でも機能する命名標準を見つけようとすることは、おそらく空想のパイです。

私の経験の早い段階で、Cで#defineマクロを使用して、Cコードをその前に使用していたPascalコードのように見せることを試みました。私はPascalでのプログラミングに非常に慣れていたので、PascalのようにCを動作させることができれば、生産性が向上するだろうと考えました。私は間もなく自分が間違っていることを発見しました。

私の生産性を高めたのは、Cを習得し、Pascal構文を他の言語に活用しようとしないことでした。

使用している別の言語でそれを行うのが間違っているという理由だけで、ある言語で何かをするのを防ぐことによって、プログラマーを潜在的に制約することになると思う。

命名規則を、変数の使用法を説明する意味のあるものに限定すると、おそらくどの言語でも良いコードが作成されます。

そもそも「list」、「new」、「var」、「this」などの名前を付けるべきではありません。どの言語でも十分に説明的ではないからです。

たとえば、javascriptからpythonへの切り替えは、すでにコンテキスト切り替えです。変数名がシフトしても、特に名前の変更が言語で慣用的である場合、それは悪いことではないと思います。難しいコンテキストスイッチは、「おい、あなたは今Pythonではなくjavascriptを書いている」ということを補強するのに役立つので、この場合に役立つと主張することさえできます。

記述変数の名前付けを使用している場合、説明する問題は最小限に抑える必要があると思います。そうは言っても、それが最小限であれば、言語間の変数の命名に起因するコンテキストシフトの受け入れも最小限になります。

ほとんどの予約語（どの言語でも）はかなり一般的です。私はよりわかりやすい変数/関数名を好むため、この問題はほとんど発生しません。チャールズ・シモニーの元の命名体系（これはハンガリー表記と呼ばれる前の70年代後半のゼロックスでのことでした）に感染したことを認めるべきです。予約語として使用します。

これが仮説的な問題ではなく、実際の問題であることがわかるまで、ガイドラインを書くことに時間を費やすべきではありません。

これが問題になる可能性のある状況の1つは、プログラミング言語間でデータ構造を共有する場合です。たとえば、サーバー側のPythonオブジェクトに反映されるJavascriptオブジェクトがクライアント側にあり、それらのメンバーに同じ名前を持たせたい場合。その場合、ルールは単純です。どの言語でも予約語である名前を使用しないでください。それでおしまい。必要に応じて、ガイドラインに記述してください。次に、より重要なタスクに進みます。

ところで、listもdictもPythonの予約語ではありません。これらは変数名として使用できますが、かなりお粗末なものです。

私の経験では、これに対する修正は、すべての言語に適用される幅広い命名規則を持つことです。JavaScript、C＃、またはその他のファンキーな言語のいずれであっても、変数とクラスの命名方法はコードベース内の標準になることができます。これが一般にこの問題の解決方法です。コンベンションは全員のコンセンサスによって合意することができます。単に大多数がガイドラインを望み、経営陣は「これが私たちのやり方です」とか、私が想像する他のいくつかの可能性を望んでいます。

ほとんどの場合、クラス名または変数名は、それほど簡単に競合しないように十分に記述的であるため、あなたが説明する識別子の問題はほとんど見られません。同時に、チームがどのようにこれを処理したいかを明確にすることよりも、他の人と協力することが重要なポイントです。

ある言語から別の言語にコードを移動する予定がない限り、これがどのように問題になるかはわかりません。どの変数名が有効であるかを個人的に忘れがちな場合は、変数名が有効であることを個人的に確信しない限り、変数名を使用しないでください。しかし、他の人が無効な変数名を使用すると、コードはコンパイルも実行もされません。したがって、他の誰かのコードで作業していて、彼らが何か「var」と呼んだ場合、それが彼らが使用しているどの言語でも有効な名前であると確信できます。

ある言語から別の言語にコードを移動する予定がある場合は、禁止されている名前のリストが必要になる場合があります。たとえば、私のCコーディングプラクティスでは、変数としてnewまたはclassを使用することを禁止しています。これにより、コードがC ++に移植しにくくなります。その場合、必要になったときにその仕事を緩和するルールを設定するのが合理的です。

小文字の先頭にあるCamelCaseに固執するだけです。どこでも動作します。これは、互換性のないシステム間で最も一般的な分母を探すことと呼ばれ、これを頻繁に行うことに気付くでしょう！