c++ - 一般的なC++の命名規則をライブラリの命名規則とどのように調整しますか

Question

ほとんどのC++命名規則ではcamelCaseIdentifiers、クラス（Person、）の場合は大文字で始まる名前、Bookingフィールドと変数（getPrice()、、）の場合は小文字で始まる名前の使用が規定されています。これらの推奨事項は、クラス（、、、）およびメソッドとフィールド（、、、）の小文字の名前を含むC++ライブラリの命名規則とは完全に一致していません。さらに複雑なのは、オペレーティングシステムとCライブラリ関数です。これらの関数には、CおよびUnixでは圧縮された小文字の名前が含まれ、Windowsでは大文字で始まる関数が含まれます。isValid()largestValuestringsetmapfstreamnames_joined_with_an_underscorefind_first_oflower_boundreverse_iteratorfirst_type

その結果、一部の識別子はC ++ライブラリ、C、またはオペレーティングシステムの命名規則を使用し、他の識別子は規定のC ++規則を使用するため、私のコードは混乱しています。ライブラリの機能をラップするクラスまたはメソッドを作成するのは面倒です。これは、類似したものに対して異なるスタイルの名前で終わるためです。

では、これらの異なる命名規則をどのように調整しますか？

score 22 · Accepted Answer

Diomidis、私はあなたの痛みを共有し、私が使用するさまざまなライブラリ/フレームワーク (MFC および/または STL/Boost) で動作するものを見つけようとして、長年にわたってさまざまなスキームを切り替えることに多くの時間を費やしてきました。STL などの単一のフレームワークで作業する場合は、そのフレームワークで使用されている命名規則をコピーして試すことができますが、別のフレームワークを導入すると、簡単にバラバラになります。

最後に、私が作成するすべての新しいコードに (Google C++ スタイルガイドラインに基づいて) 単一のスタイルを採用し、必要に応じて古いコードをリファクタリングしてこのスタイルを使用しています。さまざまな命名規則を簡単に調整することはできないため、時間を無駄にしないでください。チーム/部門/会社にスキームを適用し、それに固執します。ただし、スキームを組み合わせて使用する場合にコードが「醜い」ように見えることにこだわらないでください。

Google C++ のガイドラインは、いくつかのマイナーな修正を加えた、非常に優れた私見です。ここでガイドをチェックしてください：

https://google.github.io/styleguide/cppguide.html#Naming

score 20 · Accepted Answer

C++ を採用する方法の 1 つnaming_conventionは、これが現在の文献のほとんどのコード例で行われていることです。

これらの規則が製品コードに移行するのをゆっくりと見ていますが、多くの場所で依然として普及している MFC 命名規則との戦いです。

古い標準と戦う他のスタイルの違いは、m_メンバーを示すのではなく、末尾のアンダースコアを使用することです。

score 5 · Accepted Answer

なぜ和解する必要があるのですか？コードがコンパイルされ、作業を完了できる限り、心配する必要はありません。

score 4 · Accepted Answer

コードスタイルに関しては、私は完璧主義者になる傾向があり、これは常に私を悩ませてきました。普遍的な基準があればいいのにと思いますが、ありません。私のプロとしてのキャリアの中で、個々のプロジェクトのプログラマーが一貫している限り、それが期待できる最善の方法であることがわかりました。

最終的には、メソッド、オブジェクト、または関数がどのライブラリからのものかを知ることに帰着すると思います。それを知っていれば、プロジェクトに多くのライブラリが含まれていないと仮定すると、そのライブラリで使用されている規則を簡単に覚えることができます。使用するライブラリのコードと一致するように独自のコードを適応させようとしましたが、それは常に移動するターゲットであり、最終的にはイライラするだけです.

score 3 · Accepted Answer

正直なところ、私はライブラリをそのまま使用し、独自のコーディングスタイルに固執します。あなたはそれをラップすることができますが、それはやり過ぎのようです.

score 3 · Accepted Answer

私が取り組んでいるプロジェクトでは、プロジェクトのコード規則に従っています。他のものを呼び出すときは、そのライブラリの API を使用します。

また、ライブラリのラッピングは悪い考えだと付け加えておきます (私が取り組んでいるコードベースにはたくさんあります)。これは通常、自分の問題を解決する開発者によって行われ、原則として使用には不適切であるためです。他のすべての開発者によって。反面、高品質なラッピングは高い。

score 2 · Accepted Answer

名前の衝突を避けるために、彼らが意図的に標準ライブラリを推奨されるコーディング規約とは異なるものにすることを選択したことをずっと前に読んだことを思い出しているようです。しかし、今はそれについて言及している参考文献は見つかりません。標準ライブラリ用に予約されているため、型名に小文字を使用しないでください。アンダースコアを使用しても、同様のことが起こっていると思います。プロジェクト内のコードから標準コードを明確に分離しているため、複数の命名規則を問題とは見なしていません。私は常に、型には大文字のキャメルケースを使用し、メソッド/メンバーには小文字のキャメルケースを使用して、プロジェクトでコードを記述しています。私の現在の職場では、タイプに加えてメソッドにキャメルケースを使用しているため、非常にイライラします。しかし、彼らはハンガリーの疣贅も好きです、

score 2 · Accepted Answer

お気に入りの引用::

標準の最も良い点は、選択できるものが非常に多いことです。

私の提案は、あなたの会社のコードで最も頻繁に発生するライブラリの規則 (おそらく、boost も固執していると思われる C++ ライブラリ) を採用し、それを標準にすることです。それ以外の場合は、まったく持っていない可能性があります。

score 2 · Accepted Answer

まあ、標準ライブラリの実装方法を変えることはできないので、それについていく必要があると思います。調整に関しては、少し前に Win32 API を書いているときに、API で行われているように PascalCasing で独自のメソッドに名前を付けようとしましたが、それは正しく感じられませんでした。そのため、キャメルケースでメソッドに名前を付けることに戻りました。私はそれが混乱していることに同意しますが、他のオプションは、使用するすべての新しいフレームワークまたはライブラリにスタイルを適応させることです。次に、単一のプロジェクトで異なる規則を使用する複数のライブラリを使用するという問題があります。したがって、私のアドバイスは、独自のメソッドとクラスに適していると思われるものに固執することです。または、企業環境では、会社のベストプラクティスとガイドラインに固執します。

score 1 · Accepted Answer

違いを受け入れる必要があります。

remove_copy_if の使用を見ると、これがアルゴリズムであることがすぐにわかります。アルゴリズムには一定の保証がある (またはない) ため、これは実際にはプラスの機能です。

また、独自のカスタムアルゴリズムにも命名規則を使用しています。

c++ - 一般的なC++の命名規則をライブラリの命名規則とどのように調整しますか

10 に答える 10

Related

Reference