In primo luogo, credo di aver visto questa domanda discussa qui prima, ma non riesco a trovarla. Le mie scuse se lo trovi.
Sto iniziando un nuovo progetto e sto cercando di capire perché IsResolved e / o ResolvedOn hanno più senso per me che Risolto. Ovviamente, quando qualcosa è chiamato "CompanyName" (ad esempio), sono abbastanza fiducioso che lo testerò come una stringa. Tuttavia, quando vedo "Risolto", e so che l'oggetto che descrive potrebbe non avere un valore valido per una data di risoluzione, mi dà fastidio che devo ispezionare il tipo per determinare come testarlo: per undefined / null / etc . (come una data), o come valore booleano.
È ragionevole affermare che Is e On tipicamente fanno più che dichiarare il tipo di variabile; dichiarano l'intento? O forse semplicemente che rende il codice più chiaro per qualche altra ragione per cui non sono abbastanza capace di codificare?
Discutendo dall'altra parte, se guardo il tipo di Risolto, e vedo che è un booleano, avrò la mia risposta. Forse questo non è diverso dal sapere che avrò bisogno di ispezionare una variabile "Fattibilità" per determinare se si tratta di un int, enum o qualcos'altro. (Anche se forse proprio questo significa che "Fattibilità" sarebbe anche un nome sub-ottimale.) E a prescindere, nel caso di "ResolvedOn", devo ancora verificare se è nullable per determinare se devo anche ispezionare un "IsResolved" "valore. Qual è il punto della verbosità, che codifica una seconda volta nel nome della variabile che può essere dedotta dal tipo?
Per favore mi dia una comprensione della mano perché [Proprietà] e [Proprietà] hanno senso per me , sebbene in generale l'ungherese no. Oppure, spiega perché un'eccezione come questa non avrebbe senso?
Nota: lavoro principalmente con SQL, C # e JavaScript.