Che cos'è una buona convenzione di denominazione per le proprietà delle date? [chiuso]

Posso vedere pro e contro a tutti questi. Preoccupazioni ho pensato a:

• Il nome dovrebbe chiarire che questa è una data o è già implicita nel testo?
• Il nome dovrebbe essere riconoscibile come una data in un elenco di nomi di proprietà?
• Il nome dovrebbe terminare con il nome che suggerisce l'essenza del valore?
• Sono importanti gli ordini di token non intuitivi, ad esempio gli ordini rari o inutilizzati in inglese?
• La materia è tesa?
• Dovremmo preoccuparci che tutte queste proprietà si trovino l'una accanto all'altra quando ordinate?
• Può la semplicità di un nome di proprietà superare la vaghezza dovuta a tale semplicità?

Il mio primo giudizio è di rispondere come segue, ma voglio ancora più opinioni sull'esperienza.

• Il nome dovrebbe chiarire che si tratta di una data, poiché il nome stesso dovrebbe acquisire il contenuto essenziale del valore memorizzato. (in altre parole, sappiamo che una proprietà come Name è molto probabilmente una stringa perché i nomi sono stringhe, ma una proprietà come Start ci lascia pensare: "start ... what?"
• Il nome dovrebbe terminare (o essere interamente composto da) un nome che suggerisce l'essenza del valore memorizzato.
• La semplicità nella denominazione è buona ma non fondamentale.
• Evita gli ordini di token (word) non obbligatori; preferisci l'ordinamento linguistico naturale dei token.
• Il tempo passato dovrebbe essere evitato per qualsiasi valore che non sia sempre nel passato.
• Ordinare le proprietà per nome dovrebbe essere meno preoccupante, quindi nominarlo bene secondo i principi sopra riportati.

Questi giudizi mi portano a scegliere StartDate come scelta migliore nell'esempio fornito.

Start non è realmente un sostantivo, ma per altri esempi, potrei considerare un sostantivo da solo senza "... Date" per semplicità se non ci sarebbe confusione - per esempio, Expiration piuttosto che ExpirationDate . Per ulteriore semplicità, potrei prendere in considerazione anche una forma verbale, ad esempio Expires anziché Expiration . Ma ora mi sento come se stessi andando alla deriva in "tutto ciò che è bello" piuttosto che avere uno standard coerente.

Mi piacerebbe sapere da chiunque per aiutare a chiarire.

Mi piace il commento sull'uso della parola Data come prefisso in modo che il completamento automatico in stile Intellisense funzioni meglio.

Una cosa di cui essere consapevoli è che DateStart e DateStarted non sono equivalenti semanticamente in inglese. Uno, il primo, implica che la data non è arrivata, ma che il punto è imminente in futuro. Quest'ultimo, DateStarted, implica che la cosa sia effettivamente iniziata e in quel momento specifico. A seconda di ciò che il tuo sistema sta cercando di ottenere, potresti aver bisogno di entrambi i campi.

Ho diviso i campi della data in due categorie

a) Quelli che rappresentano solo un singolo punto nel tempo sono sempre xxxDate - ad es. OrderDate, InvoiceDate, BirthDate, EnrolmentDate ...

b) Quelli che rappresentano il punto iniziale o finale di un intervallo di tempo sono sempre xxxFrom o xxxUntil, anche per quelle classi o record che contengono solo una estremità dell'intervallo - ad es. PriceApplicableFrom, DiscountValidUntil ...

Il modo in cui cerco sempre di farlo è di differenziare le date (e le ore) dagli intervalli temporali, in base al loro contesto nel dominio del problema.

Ad esempio, un valore Date rappresenterebbe un momento specifico nel tempo che interessa nel dominio problematico: un OrderDate , un dipendente StartDate , ecc. Qualsiasi intervallo di tempo prima o dopo questi punti specifici nel tempo non è rilevante nel dominio problematico come intervallo di tempo . Questi tipi di valori chiamo sempre somethingDate .

Per periodi di tempo in cui sono rilevanti nel dominio problematico - come intervalli di tempo - quindi chiamo i punti finali del time span somethingStart / somethingStop , o somethingBegin / somethingEnd , dove "qualcosa" è un termine nel dominio del problema che rappresenta un intervallo di tempo. Ad esempio, FallTermBegin / FallTermEnd o FlightTimeStart / FlightTimeStop .

Poiché il termine dominio stesso indica un intervallo di tempo, non è necessario includere Date o Time nel nome della variabile, poiché si conosce già la sua natura. Inoltre, se presti sufficiente attenzione al nome dell'intervallo di tempo del dominio, le unità sono in genere anche intuitive, ad esempio ore per FlightTime o giorni per FallTerm .