Wenn ich eine Klasse habe, die eine DateTime speichert:
%Vor%Wie soll ich die DateTime-Eigenschaft benennen? Oder sollte ich die Eigenschaft in 2 Eigenschaften teilen: 1) Datum 2) Zeit?
edit: Ich habe nach einem Eigenschaftsnamen gesucht, der die Schlussfolgerung liefert, dass sein Wert sowohl ein Datum als auch eine Zeit ist, keine Eigenschaft für Protokolleinträge (z. B. DateCreated liefert keine Schlussfolgerung, dass er auch die Zeit teilt Eintrag wurde erstellt und umgekehrt).
When ist ein guter Name in einem Protokoll.
Edit: und aus den offiziellen Benennungsrichtlinien: " Do erwägt, eine Eigenschaft wie ihren Typ zu benennen." Das ergibt
%Vor%Wählen Sie einen Namen, der Ihrer Meinung nach die Eigenschaft am besten beschreibt. Und, nein, spalte die Eigenschaft nicht.
Wenn LogEntry für die Protokollierung verwendet wird, können einige andere Protokollplattformen dies folgendermaßen tun:
log4net ruft TimeStamp in LoggingEventData struct.
aufNLog nennt es TimStamp in der LogEventInfo -Klasse.
Die Enterprise Library ruft timeStamp in der Klasse LogEntry auf.
Microsoft nennt es DateTime in der TraceEventCache -Klasse (TraceEventCache ist in TraceListener Trace * -Anrufe übergeben. DateTime ist der Zeitpunkt, zu dem die Protokollierungsnachricht generiert wurde.)
Alles, was einfach ist, steht nicht in Konflikt mit anderen Namen wie DateTime selbst und ist deskriptiv. Da es sich um einen Protokolleintrag handelt, könnten Sie es EntryTime nennen.
Anders als die meisten Vorschläge hier würde ich DateCreated verwenden, weil es intuitiv ist, mit der Eingabe von "date" zu beginnen, wenn Sie nach dem Erstellungsdatum suchen. Ich glaube auch nicht, dass es ein Problem gibt, nur "Datum" erscheint im Namen und nicht "Zeit". Das ist häufig und akzeptabel.
Sie sollten eine Konvention für Zeitstempel in Ihrer Codebasis auswählen und sich dann daran halten. Zum Beispiel rufe ich alle meine Zeitstempel "update_at" oder "created_at" auf. Andere Optionen wären CreatedDate und UpdateDate.
Teilen Sie Datum und Uhrzeit nicht in separate Eigenschaften auf. Der einzige Grund, warum Sie das tun würden, wäre eine Art von Optimierung für die Verarbeitung großer Datenmengen, bei der Sie die Datumsanalyse explizit als Engpass identifizieren.
Was für Sie (und Ihr Team) Sinn macht. Sie könnten EntryDateTime verwenden, da dies sinnvoll wäre. Wenn Sie das Datum und die Uhrzeit separat benötigen, ist es sinnvoll, separate Methoden zu erstellen. Es ist jedoch nicht erforderlich, die beiden einfach zu trennen, um Gründe zu nennen.
Sie sollten einen beschreibenden Namen als was die Eigenschaft tut wählen ...
Wenn es für ein CreateDate dann "CreateDate" .. ziemlich selbsterklärend ist.
Für die Protokollierung können Sie "LoggedTimeStamp", "LoggedDateTime" usw. verwenden.
Ein Datum ist nur ein grobkörniges Maß der Zeit, das 24 Stunden in derselben Einheit zusammenfasst. In Bezug auf Hühner und Eier kommt die Zeit vor dem Datum: Zeit ist die physische Einheit, Datum ist nur eine Maßeinheit. Der DateTime-Datentyp hilft dabei, das Problem zu verwirren, und viele Menschen denken, dass Zeit ein Bruchteil von Date ist. Das ist völlig falsch! Einstein hat nicht von Space Date gesprochen, oder?
Ihre Namen sollten beschreibend sein für das, was tatsächlich passiert, im Gegensatz zur Angabe des Datentyps (Lezinski oder was auch immer sein Name hatte, hatte eindeutig keine Intellisense zur Verfügung).
Also wäre entweder LogTime oder EntryTime der beste Name.
Bei der Verwechslung des Datentyps, der Maßeinheit und der physikalischen Entität handelt es sich um konzeptionelle Fehler, die Programmierer auf den Weg im Garten führen.
Und es ist nicht der Garten Eden.
Der Kommentar zu der Frage besagt, dass die Frage nicht klassenspezifisch sein sollte.
Die richtige Antwort ist jedoch klassenspezifisch, sie bezieht sich nicht auf die Tatsache, dass die Eigenschaft eine DateTime ist (wir wissen bereits, dass es sich um ein Datum und eine Uhrzeit handelt, weil es sich um Daten und Zeit handelt). Die Eigenschaft existiert aus einem bestimmten Grund, und deshalb sollten wir sie bei der Benennung berücksichtigen.
Während eine Anfrage für einen nicht-klassenspezifischen Eigenschaftennamen gemacht wird, biete ich an:
%Vor%:)