個人のライブラリにどのように名前を付けますか？
私は物事に名前を付けるのがかなり苦手です。
私が一般的に思いつくことができる唯一の名前は「ヘルパー」です。たとえば、パスを操作するためのヘルプ機能を含むヘッダーファイルがある場合、それを「ヘルパー」ディレクトリ内に置き、「path-helper.hpp」などの名前を付ける傾向があります。
明らかに、それは悪い命名規則です。 :)
自分のヘッダーとライブラリを常に参照するために使用できるフォルダー（および名前空間）に一貫した名前付けスキームを設定したいのですが、入力または覚えやすい名前（boostなど）を見つけるのに問題があります）...だから、私はそれらのうちのいくつかを「ヘルパー」または「stdext」などと呼んでしまいますが、これは素晴らしいアイデアではありません。
覚えやすく入力が簡単で、汎用的ではないライブラリの名前をどのようにして見つけますか（「ヘルパー」、「std」、「stdext」など）。
これを行う方法についての提案はありますか？
ヘルパー関数をテーマ別にグループ化し、ライブラリ名にテーマを含めるようにしてください。 「ヘルパー」のようなライブラリ名は一般的すぎるかもしれませんが、「PathHelper」、「FileIOHelper」のような名前は、そのライブラリで期待できる関数についてほとんど述べています（個人的には「...ユーティリティ」を好みますが、それは個人的な好みの問題）。たとえば、「MathUtilities」、「StringUtilities」、「ConfigUtilities」、「DBUtilities」などのlib名があります。
もちろん、私たちのチームのより大きなライブラリの場合は、最後に総称のない名前を使用します。正直に言うと、特定のトピック名でうまくグループ化されない関数やクラスのために、「Common」と呼ばれるライブラリもあります。しかし、そのlibは小さく保つようにしています。
一般的に、それは私にとって有機的なプロセスです。
名前空間は、主にフォルダ名を反映する傾向があります。これは、そのようにして検索する方が簡単だと思うからです。
一般に、企業プロジェクトには名前空間の前に会社のプレフィックスがあり、個人プロジェクトの場合は、名前をproject-prefix.folderとfolderの間で切り替えます。
「メイン」フォルダはその名前から明らかである傾向があり、一般的にそれらの機能に関連しています-「フー」。大規模なプロジェクトの場合は、メインフォルダーを分割して、フォローしている可能性のある主要なプログラミングパラダイムを反映させます。したがって、MVVMの場合、名前の例として「Foo.View」、「Foo.ViewModel」、および「Foo.Model」があります。
常に、他に適合しないヘルパー関数がプロジェクトに侵入し始めます。まず、「common」または「utilities」タイプのフォルダーから始めて、それらを上陸させます。 「ヘルパー」、「ベース」、および「コア」は、最初の着陸場所でも同様に機能します。
私は、サブジェクトやアクションに基づいて関数に名前を付けようとしています。したがって、PathManager、PathCheckerなどを使用できます。多くの場合、サブジェクトに関連するいくつかのアクションがあることを知っているので、サブジェクトにちなんでクラスに名前を付け、必要に応じてメソッドを追加します。ここでは、シソーラスが役に立ちます。
オブジェクトの命名のしやすさと、関数が何をすることになっているのかをどれだけうまく説明できるかとの間には高い相関関係があることがわかりました。私の個人的なチェックポイントの1つは、名前を付けるのに苦労している場合、関数が実際に何をしているのかを振り返る必要があるということです。機能の問題を修正すると、名前は簡単にわかります。
さらにヘルパー関数を集めたら、それらを独自のフォルダーや名前空間に移行します。ルートプロジェクトからフォルダーを取得するか、ユーティリティフォルダーへのサブフォルダーを取得するかは、機能の性質と量によって異なります。
GlenH7と同様に、私は「-misc」ライブラリを使用する傾向があります。ここで、orgは、現在の雇用主が誰であろうと、3文字または4文字の省略形です。
新しいランダム関数は、パターンが出現するために十分に蓄積されるまでそこに配置されます。その時点で、それらをグループ化し、関連する関数をよりわかりやすい名前のライブラリーに引き出し、必要に応じてクライアントコードをリファクタリングします。
ライブラリのサイズを管理しやすくするために、少しの規律が必要な場合がありますが、最近の私の*-その他のライブラリは、かなり小さいままである傾向があります。
（開発とテストの自動化をサポートするための「メタレベル」関数を含む「devauto」と「testauto」ライブラリも常に持っています）。
私もこれがとても下手です。私の実用的なアプローチは、妥当な名前が見つかるまで、日付、プロジェクト、場所、またはその両方で名前を充実させることです。
他の人には読めないことはわかっていますが、私自身はすぐにそれを認識することができます。そして、これらのライブラリのほとんどは、とにかく私にとって使い捨てになります。
それが私なら、パスライブラリだけを持っています（パスコンポーネントを含んでいるファイルシステムライブラリである可能性が高いです）。それは私が仕事を成し遂げるために必要な正確なインターフェースを提供するでしょう。確かに、その90％はboost.filesystemまたはそこにあった言語ファイルシステムのlibの薄いラッパーですが、私のコードはこのNice整合性のあるライブラリのみを参照します。その関数がX、X-helper、X-utils、またはX-extにあったかどうかを覚えようとはしません。 Xが助けを必要とするなら、それはXを修正する時です、コードのために新しいランダムな場所を発明するのではありません。