多言語環境で慣用的なコードを書くのはどれくらい難しいですか？
私は、いくつかの別々のプラットフォームにまたがるプロジェクト/製品の小さなチーム（2つのプライマリーと1つまたは2つの他の時折の貢献者）で働いています。 Arm0チップ上のストレートCに組み込みファームウェアを実行します。 pythonと、サイズがRaspberry Piと同様の小さなLinuxコンピューター用のシェルスクリプトを少し記述します。iOSアプリはSwiftで記述します。Android = Kotlinのアプリ。AndroidとiOSアプリの間には、ある程度の平等を求めています。
まれなのは、私が1つのコードベースだけで作業する日です。私は自分自身が2つの極端の間で引き裂かれていることに気づきます：
1）各言語/プラットフォーム/環境で、その特定のコミュニティのコーディング規約、ベストプラクティス、およびイディオムをすべて遵守します。
2）それらの収束した「メルティングポット」になる傾向がある独自の慣用句/イディオムをロールバックします。
このようなもののさらにマイナーな例は、条件式の括弧です。 CとKotlinはそれらを必要とします。 Swiftはそうではありません。しかし最近、私はそれらをSwiftコードに入れることに気づきました。なぜなら、一貫性を保つのが簡単だからです。
同時に、Cがセミコロンを必要とするからといって、すべてのPython/Kotlin/Swiftにセミコロンを追加していません。
どこでハイブリダイズするか、どこでハイブリダイズしないかに関するこれらの決定は、私には恣意的だと感じます。基本的に個人的なスタイルの問題。他の人がこれを行うためのより原理的なアプローチを構築できたのかどうか、私は興味があります。または、他の人がこの道を進んでから、すべての努力を拒否し、各領域で完全に慣用的になります（各システムには、他のシステムよりも慣用的な「パターン」があるため、これは私には現実的ではないようです） 。
あなたが扱っている才能のレベルを知ることは良いことだと思います。 1つのエリアでほとんどの作業を行う人が1人いる場合は、そのエリアの規則を確立してもらうことをお勧めします。ただし、その地域で他の人を雇うつもりであることがわかっている場合は、人気のあるコーディングスタイルを個人的に課して、自分自身に小さな足を引っ張ることができます。
また、性格の観点からスタッフはどの程度柔軟ですか？彼らの習慣が乱されないことがどれほど重要ですか？これらは重要な考慮事項です。 Steve McConnellがCode Completeで説明しているように、十分に異なるコーディングスタイルは、コードを理解するコーダーの能力に影響を与える可能性があります。
これらの規則は、開発者にとって問題になっていますか？私は非常に異なる言語でいくつかの異なるプロジェクトでコードを書かなければならない会社で働いています。特に、C/C++、C＃、Java、Qt/Qml、JavaScript + Web（CSS、XHTMLなど）があります。私はアーキテクトです。これらのプロジェクト/チームに適切なスタイルの規則を設定する責任があります。
使用する言語ごとに、その言語で公開されている人気のスタイルガイドに基づいたスタイルを選択することをお勧めします。これらのスタイルガイドには信じられないほどの量の考えがあります、私はそれらを十分に推薦することはできません。それらを読むことは、それ自体が喜びになることができます。
同様のスタイルを可能にするのに十分類似している言語の場合、これらの言語間でほとんど共有されている同様のスタイルを採用することをお勧めします。たとえば、C/C++（もちろんカスタマイズしましたが、正しいと感じます）とC＃の両方にMicrosoftのDotNetスタイルガイドを使用しています。ただし、一部の言語では、互換性のない大文字の規則が適用されます。
たとえば、C/C++やC＃の場合と同じように、Haskellメソッド名を大文字にする必要はありません。言語はそれを許可しません。このような場合は、公開されているHaskellコードのスタイルガイドから選択し、コーチングとレビューを通じてそれを実施してください。これにより、深刻なレッグワークを行う必要がなくなります。
フレームワークを使用している場合、フレームワークは、フレームワークを操作しやすくする独自の規則を制約または提供する場合があります。それだけでなく、フレームワークを操作するために実際に規約が必要になる場合があります。もちろん、これらの場合、フレームワークに屈して例外を作ります。慎重に、前例があるようにスタイルガイドを変更してください。
これがお役に立てば幸いです。足りないものがあれば教えてください。