個人のライブラリにどのように名前を付けますか？[閉まっている]

私は物事に名前を付けるのがかなり苦手です。

私が一般的に思いつくことができる唯一の名前は「ヘルパー」です。たとえば、パスを操作するための支援関数を含むヘッダーファイルがある場合、それを「ヘルパー」ディレクトリ内に置き、「path-helper.hpp」などの名前を付ける傾向があります。

明らかに、それは悪い命名規則です。:)

自分のヘッダーとライブラリを常に参照するために使用できるフォルダー（および名前空間）に一貫した名前付けスキームを設定したいのですが、入力や覚えやすい名前（などboost）を見つけるのに問題があります...それらの一部を「ヘルパー」や「stdext」などと呼ぶことになってしまいますが、これは素晴らしいアイデアではありません。

覚えやすくタイプしやすく、一般的ではないライブラリの名前をどのようにして見つけますか（「ヘルパー」、「std」、「stdext」など）。

これを行う方法についての提案はありますか？

ヘルパー関数をテーマ別にグループ化し、ライブラリ名にテーマを含めるようにしてください。「ヘルパー」のようなライブラリ名は一般的すぎるかもしれませんが、「PathHelper」、「FileIOHelper」のような名前は、そのライブラリで期待できる関数についてほとんど述べています（個人的には、「...ユーティリティ」を好みますが、それだけです。個人的な好みの問題）。たとえば、「MathUtilities」、「StringUtilities」、「ConfigUtilities」、「DBUtilities」などのlib名があります。

もちろん、私たちのチームのより大きなライブラリの場合は、最後に一般的な用語のない名前を使用します。正直に言うと、特定のトピック名でうまくグループ化されない関数やクラスのために、「Common」と呼ばれるライブラリもあります。しかし、そのlibは小さく保つようにしています。

一般的に、それは私にとって有機的なプロセスです。

名前空間は、主にフォルダ名を反映する傾向があります。これは、そのようにして検索する方が簡単だと思うからです。

一般に、企業プロジェクトには名前空間の前に会社のプレフィックスがあり、個人プロジェクトの場合は、名前のプロジェクトプレフィックス。フォルダーとフォルダーのみを切り替えます。

「メイン」フォルダはその名前から明らかである傾向があり、一般的にそれらの機能に関連しています-「Foo」。大規模なプロジェクトの場合は、メインフォルダーを分割して、フォローしている可能性のある主要なプログラミングパラダイムを反映させます。したがって、MVVMの場合、名前の例として「Foo.View」、「Foo.ViewModel」、および「Foo.Model」があります。

常に、他に適合しないヘルパー関数がプロジェクトに侵入し始めます。まず、「common」または「utilities」タイプのフォルダーから始めて、それらを最初に配置します。「ヘルパー」、「ベース」、「コア」は、最初の着陸場所でも同様に機能します。

私は、サブジェクトやアクションが実行するアクションに基づいて関数に名前を付けようとしています。したがって、PathManager、PathCheckerなどを使用できます。多くの場合、サブジェクトに関連するいくつかのアクションがあることを知っているので、サブジェクトにちなんでクラスに名前を付け、必要に応じてメソッドを追加します。ここでは、シソーラスが役に立ちます。

オブジェクトの命名のしやすさと、関数が何をすることになっているのかをどの程度うまく説明できるかの間には、高い相関関係があることがわかりました。私の個人的なチェックポイントの1つは、名前を付けるのに苦労している場合、関数が実際に何をしているのかを振り返る必要があるということです。機能の問題を修正すると、名前は簡単にわかります。

さらにヘルパー関数を集めたら、それらを独自のフォルダーや名前空間に移行します。ルートプロジェクトからフォルダーを取得するか、ユーティリティフォルダーへのサブフォルダーを取得するかは、機能の性質と量によって異なります。

GlenH7と同様に、私は「-misc」ライブラリを使用する傾向があります。ここで、orgは、現在の雇用主がたまたまある人の3文字または4文字の省略形です。

新しいランダム関数は、パターンが出現するために十分に蓄積されるまでそこに配置されます。その時点で、それらをグループ化し、関連する関数をよりわかりやすい名前のライブラリーに引き出し、必要に応じてクライアントコードをリファクタリングします。

ライブラリのサイズを管理しやすくするために、少しの規律が必要な場合がありますが、最近の私の*-その他のライブラリはかなり小さいままになりがちです。

（私はまた、開発とテストの自動化をサポートすることを目的とした「メタレベル」関数を含む「devauto」と「testauto」ライブラリも常に持っています）。

それが私なら、パスライブラリだけを持っています（パスコンポーネントを含むファイルシステムライブラリである可能性が高いです）。それは私が仕事を成し遂げるために必要な正確なインターフェースを提供するでしょう。もちろん、その90％はboost.filesystemまたは存在するあらゆる言語のファイルシステムlibの薄いラッパーですが、私のコードでは、この素晴らしい一貫したライブラリのみが表示されます。その関数がX、X-helper、X-utils、またはX-extにあったかどうかを覚えようとはしません。Xが助けを必要とするなら、それはXを修正する時です、コードのために新しいランダムな場所を発明しないでください。

私もこれがとても下手です。私の実用的なアプローチは、妥当な名前が見つかるまで、日付、プロジェクト、場所、またはその両方で名前を充実させることです。

他の人には読めないことはわかっていますが、私自身はすぐに認識できます。そして、これらのライブラリのほとんどは、とにかく使い捨てになってしまいます。