複数の異なるライブラリを使用する場合のコーディングスタイル

私は、いくつかのCライブラリを含むいくつかのライブラリを使用するいくつかのC ++コードに取り組んでいますが、それらはすべて異なるコーディングスタイルを持っています。使用可能な段階に達すると、オープンソースになります。コードをチェックアウトして1つのバグを修正したり、1つの機能を追加したりする短期間の寄稿者の混乱を最小限に抑えるのはどれですか。

• 使用されるライブラリの一般的なコーディングスタイルと一致しない場合がある場合でも、アプリケーション全体で1つの一貫したコーディングスタイルを使用します。
• ライブラリが特定のモジュールで頻繁に使用される場合、そのモジュールのそのライブラリの一般的なコーディングスタイル（ライブラリの独自のコードやドキュメントで使用されているコーディングスタイル）に準拠します。

私の考えでは、後者を使用すると、その特定のライブラリーの専門家が1回限りの貢献をしやすくなり、開発中にチュートリアル/サンプルコードを組み込むのが容易になります。ただし、アプリケーション全体でコーディングスタイルに一貫性がなくなります。各アプローチの長所と短所は何ですか？

それはプロジェクト全体がどれだけ大きくなるかにかかっていると思います。

極端な例として、1 Mlocプロジェクトがあるとします。その大規模なプロジェクトの場合、関係するすべての領域で1人の個人が「専門家」になることはほとんどありません。したがって、この場合、各主要コンポーネントの既存のコードスタイルを使用します。新しい開発者は領域を選択し、それを学習します。異なるコードスタイルを持つ他の多くのコンポーネントが表示されることはほとんどありません。

プロジェクトがはるかに小さく、個人にコードベース全体を理解させる可能性が高い場合は、主要なコードスタイルを選択し、それを使用します。この場合、新しい開発者はプロジェクトのすべての領域で作業する可能性が高いため、プロジェクト全体で一貫性を保つ方が理にかなっていると思います。

中規模のプロジェクトは、おそらくこの決定を下すのが最も難しいでしょう。この場合、各アプローチのコストを検討し、長期的に最も安価であると考えるアプローチを決定する必要があります。中規模プロジェクトは、通常、完全なスタイルのリファクタリングが法外に高価に見えるほどに成長していることが課題です。特定のコードスタイルをグループ化するように配置できるかどうかを確認するには、コードツリー構造をもう一度確認することをお勧めします。

いずれにせよ、最終的な決定は、このパッケージをまとめるチームに任せる必要があります。

上から私の推論を変えるかもしれない外れ値のいくつか：

• 1つ以上のモジュールがひどいスタイルを持っている場合、大規模なプロジェクトであっても、それを維持する意味はありません。はい、スタイルは主観的ですが、あなたとあなたのプロジェクト参加者が本当に、特定の領域の流れ方が気に入らない場合は、古いスタイルを核にしてより良いものにします。

• すべてのスタイルが互いにかなり近い場合、「これが新しい方法です」と宣言し、すべての新しいコードと重要なリファクタリングにそれを使用するのも同じくらい簡単かもしれません。これはレビューに少々苦痛をもたらすかもしれませんが、私の経験では、ほとんどの人はこのアプローチに適応するのにかなりの能力があります。また、古いコードがどこにあるかを示す明確な印も提供します。

• 言語に追加された新しい機能に基づいてスタイルが変更される場合があります。C ++は長年にわたって多くの機能を採用しています。古いスタイルを、必要に応じて、これらの機能を利用する新しいスタイルにリファクタリングすることは理にかなっています。

• 一部のライブラリには、特に慣用的なアプローチまたはスタイルがあります。もしそうなら、それがプロジェクトの他の部分と衝突するかもしれないとしても、私はそのライブラリーのためにそのスタイルを使い続けます。ここでの意図はfrobnosticators、他のプロジェクトで作業している誰かがあなたのプロジェクトでも作業する可能性を高めることです。

一部のコメントでは、命令型およびオブジェクト指向のスタイルが考慮事項として言及されました。

特定のスタイルで「重い」モジュールは、モジュールが中規模またはそれ以上のサイズである場合、おそらくそのままにしておく必要があります。私は3つの主要なスタイル（命令的、客観的、および機能的）を扱い、重い命令的スタイルをOOスタイルにリファクタリングしました。中程度またはそれ以上の量のコードでは、リファクタリングが（例外的に）困難になる可能性があります。リファクタリングを支援するためのツールのサポートがなかったため、私の経験は混乱しました。

非常に命令的なスタイルのモジュールと、特定の開発ニッチで慣用的なモジュールとの間に高い相関関係があると想像します。これは、外れ値で指摘した最後のポイントに戻ります。したがって、その機能で見つけられるモジュールはすべてそのようになり、そのドメインの専門家がプロジェクトでも簡単に作業できるようにしたいとします。しかし、オプションがあり、チームがそのモジュールのスタイルを気に入らない場合は、オプションを調査します。

同様に、OOスタイルのモジュールを使用して、OOの原則が過度に適用され、誤って使用されています。例として、インターフェースは多重継承の代わりとして使用されていました。そして、ご想像のとおり、これは大まかな実装でした。そのモジュールのリファクタリングを合理的に進めることができましたが、代わりに使用できるより良いパッケージを見つけたので、最終的にそのアプローチを放棄しました。

少なくとも考慮すべき複数のレイヤーがあるように聞こえます：

1. 既存のライブラリとそれらへの変更。
2. これらのライブラリの新しい単体テストコード。
3. 抽象化レイヤー。
4. 抽象化レイヤーによって提供されるAPI。
5. 抽象化レイヤーを使用したコード例とテスト。

すべてのコードを共通のスタイルにリファクタリングするだけでは意味がないと仮定します。

それぞれを順番に取り入れます：

1. 既存のコードベースの場合は、おそらくそのスタイルを維持する必要があります。
2. 既存のコードの新しい単体テストコードは、特に古いコードとどの程度統合されているかに応じて、灰色の領域にあります。しかし、おそらく、私はそれを「好ましいスタイル」で作ろうとします。
3. 抽象化レイヤーの新しいコード。これが本当に別のコードレイヤーであることを確認することで、コードがレガシースタイルと多くのインターフェースを行っている場合でも、優先スタイルを使用するのに問題はありません。ほとんどのコードは他のスタイルとインターフェイスする必要がありますが、これが問題であるとは一度も知りませんでした。
4. 明らかに、API自体が最も多くの考えを必要とし、最大のユーザビリティのニーズを満たします。
5. 同様に、任意の例またはテストコードは、好みのスタイルで記述できる必要があります。抽象化の完全性（つまり、が下位層を完全に隠すかどうか）に応じて、これは簡単な場合と難しい場合があります。もちろん、将来のクライアントコードが読み取り可能であることを確認することは、主要な目的の1つになります。

私が個人的に見つけたいくつかのことは、大きなレガシーコードベースがあることです：

• 優先スタイルを設定してコード変更を強制しても、すべての古いコードが新しいスタイルに移行されるわけではありません。

• ほとんどのエンジニアは、特定のライブラリの既存のスタイルを（多かれ少なかれ）コーディングする傾向があります。それ以外の場合は、多くの強制が必要になります。

• 従来のライブラリで優先スタイルを要求すると、そのライブラリのスタイルに多くの不整合が生じる傾向があります。したがって、純粋にプレゼンテーションに関連する標準の場合、コードの堅牢性とは対照的に、それらを要求することの多くの利点を見ることは困難です。

最後の問題（トピックとは少し外れていますが、私は適切だと思います）として、一部のエンジニアは、自分が最もよく知っているスタイル標準以外のスタイル標準に固執するのに苦労しています。私は、チームにスタイルの決定に関与し、賛同が得られることを確認することを強くお勧めします。そうすることで、混合コードで標準を実際に適用するためのはるかに良い立場になります。

サードパーティのモジュールを多く含む大きなプロジェクトを開発している場合に備えて、@ MetaFightに同意します。

問題を実際の単語の問題にマッピングしてみましょう：「家に静かなライフスタイルがあるとしましょう。あなたは静かな場所が好きです。大声で話すことも、家族の誰かがそうすることも好きではありません。あなたの家のために何かを持ち込むために毎日外のさまざまな人々。彼らは必ずしも低い声で話すこともありません、その場合、あなたはそのような人々を扱う間にあなた自身に従って形成します。したがって、これらの人々のためのインターフェースまたはラッパーは単にあなたの仕事を行うことにする。「ダムの例を...笑

しかし、私のポイントは、内部の元のコーディングスタイルを維持しながら、これらのラッパーを通じてこれらのライブラリーを使用するような方法で、コーディング標準に従ってそのようなライブラリーのラッパーを作成することです。

MetaFightの+1。

プロジェクト全体で単一のコーディングスタイルを使用することで、混乱を最小限に抑えることができます。そもそもコーディングスタイルを使用するポイントは、コードを読みやすく変更しやすくすることです。

ライブラリの内部で使用されているコードスタイルについては、関係ないと思います。ライブラリが必須である場合は、OOラッパーを作成することで問題ありませんが、ライブラリのサンプルや内部と同じコードスタイルを使用する必要はありません。