日付プロパティの適切な命名規則は何ですか？
日付変数またはプロパティの適切な命名規則とは、C＃などのオブジェクトベースの強く型付けされた言語（および日付データベース列の拡張）のことですか？ 「日付」という言葉を使っていますか？
正規の「作成」または「更新」日付/時刻プロパティの例を避け、代わりに別の一般的な例を選択します。これらの名前のいずれかを回避する技術的、ドメイン固有、またはユーザーの理由がないと仮定して、間隔（カレンダー時間の期間）が開始した、または開始する日付を含むプロパティには、どのような名前を付けますか？
StartDateStartedDateDateStartedDateStartDateOfStartStartedStartsStart
（この質問は、おそらく「日付」の代わりに「時間」を使用して、日付と時刻のプロパティについても尋ねられる可能性があります。）
これらすべての長所と短所を見ることができます。私が考えた懸念：
- 名前はこれが日付であることを明確にする必要がありますか、それともタイプからすでに暗示されていますか？
- プロパティ名のリストにある場合、名前は日付として認識できる必要がありますか？
- 名前は、値の本質を示す名詞で終わる必要がありますか？
- 英語では珍しいまたは未使用の順序など、直感的でないトークンの順序が問題になりますか？
- 時制は重要ですか？
- 注文したときに、そのようなすべてのプロパティが互いに近くにあることを心配する必要がありますか？
- プロパティ名の単純さは、その単純さのために曖昧さを上回りますか？
私の最初の判断は次のように答えることですが、私はまだ経験からもっと意見を求めています。
- 名前自体が日付であることを明確にする必要があります。名前自体が、格納されている値の本質的な内容をキャプチャする必要があるためです。 （つまり、名前が文字列であるため、
Nameのようなプロパティは文字列である可能性が高いことがわかりますが、Startのようなプロパティは、「開始...何ですか？」 - 名前は、格納されている値の本質を示す名詞で終わる（または完全に構成される）必要があります。
- 命名の単純さは良いですが、最優先ではありません。
- 非自発的なトークン（Word）の順序付けは避けてください。トークンの自然言語順を優先します。
- 常に過去とは限らない値については、過去時制を回避する必要があります。
- 名前によるプロパティの順序は、上記の原則によって適切に名前を付けるよりも、それほど心配する必要はありません。
これらの判断により、与えられた例ではStartDateを最良の選択肢として選択するようになりました。
Startは実際には名詞ではありませんが、他の例では、混乱がない場合は、単純にするために「... Date」のない名詞だけを検討する場合があります（たとえば、ExpirationではなくExpirationDateなど）。さらに単純化するために、動詞形式も検討する場合があります。たとえば、ExpiresではなくExpirationを使用します。しかし、今では、一貫した基準を持つのではなく、「気分が良いもの」に向かっているように感じています。
明確にするのを助けるために誰かから連絡をもらいたいです。
Intellisenseスタイルのオートコンプリートがより適切に機能するように、Word Dateをプレフィックスとして使用することについてのコメントが好きです。
その際に注意しなければならないのは、DateStartとDateStartedは、英語では意味的に同等ではないということです。前者の1つは、日付が到着していないことを意味しますが、ポイントは将来に近づいています。後者のDateStartedは、事が実際に開始され、その特定の時間に開始されたことを意味します。システムが何を達成しようとしているかに応じて、両方のフィールドが必要になる場合があります。
日付フィールドを2つのカテゴリに分割しました
a）単一の時点を表すものは常にxxxDateです。 OrderDate、InvoiceDate、BirthDate、EnrolmentDate ...
b）時間範囲の開始点または終了点を表すものは、範囲の一方の端のみを保持するクラスまたはレコードであっても、常にxxxFromまたはxxxUntilです。 PriceApplicableFrom、DiscountValidUntil ...
私がいつもそれをしようとする方法は、日付（および時間）を問題のドメインでのコンテキストに基づいて、タイムスパンから区別することです。
たとえば、Dateの値は、問題のドメインで関心のある特定の時点（OrderDate、従業員のStartDateなど）を表します。これらの特定の時点の前後の期間は、問題のドメインでは関係ありません。 期間として。これらの種類の値は、常にsomethingDateと呼びます。
ある問題のドメインに関連する時間スパンについて-時間スパンとして-次に、時間スパンのエンドポイントにsomethingStart/somethingStop、またはsomethingBegin/somethingEndという名前を付けますここで、「何か」は、問題のドメイン内の期間であり、期間を表します。たとえば、FallTermBegin/FallTermEnd、またはFlightTimeStart/FlightTimeStop。
ドメインターム自体は期間を意味するため、変数名にDateまたはTimeを含める必要はありません。その性質はすでにわかっているためです。また、ドメインタイムスパンの名前に十分な注意を払うと、単位は通常、FlightTimeの時間やFallTermの日数など、直感的にもわかります。