Distingue tra le variabili utilizzate e non utilizzate nelle proprietà

By being able to differentiate, I would quickly know if I should use the property or the underlying variable to change/set the value.

No. Se sei in grado di differenziare, puoi rapidamente sapere che puoi utilizzare la proprietà o la variabile sottostante, ma non se quale dei due dovrebbe utilizzare.

Quando scrivi un codice all'interno di una classe usando una proprietà o la "variabile sottostante" (se ce n'è una), ci sono 3 possibili casi:

• l'utilizzo della proprietà è corretto, l'utilizzo della variabile sarebbe errato (c'è una logica nella proprietà implementata che deve essere eseguita)
• usare la variabile è corretta, l'uso della proprietà sarebbe sbagliato (c'è una logica nella proprietà che non vuoi essere eseguita esplicitamente)
• non ha importanza (non c'è logica, probabilmente potresti usare una proprietà automatica)

(vedi, ad esempio, questo post SO precedente ).

Quindi, ogni volta che la variabile nel codice deve essere utilizzata, è necessario pensare su quale dei tre casi si applica e agire di conseguenza. Nessuna convenzione di denominazione di braindead può sostituire la necessità di prendere una decisione ragionevole "per caso" e non importa se si utilizza un "trattino basso" per distinguere una proprietà da una variabile, o maiuscole / minuscole del primo carattere della variabile nome, o qualche altra convenzione prefisso / suffisso.

La migliore "pratica di codifica" per gestirlo è mantenere le classi piccole, leggibili e mantenibili, in modo che sia più facile decidere se la logica deve essere eseguita o meno.

What are the alternatives to this problem.

Credo che uno dei migliori modi per evitare i problemi derivanti dalla combinazione di proprietà e variabili private sia il principio di separazione delle operazioni di integrazione (forse uno dei principi meno noti nello sviluppo del software), che può essere visto come un'estensione del Principio di Responsabilità Singola o del Principio di Astrazione a Livello Singolo .

Separate il vostro codice in metodi che integrano (cioè chiamate altri metodi dalla stessa base di codice - che possono essere estesi alle proprietà, poiché sono metodi alla fine) e quelli che operano (cioè implementate la logica, chiamate i metodi API) ed evitate mescolare quei due.

Aderire a questo principio ti costringerà a pensare all'uso delle tue proprietà e a usarle correttamente.

Due note a margine: Primo: prova! I test aumenteranno la fiducia nel codice scritto e molto probabilmente saranno in grado di cogliere gli errori derivanti dall'errato utilizzo dei campi di supporto. Secondo: mi sembra che le tue classi diventino troppo grandi se rischi di mescolare campi di backing e campi "normali" privati. Mantieni le tue classi piccole e aderisci al Principio di Responsabilità Unico.

In questi giorni, l'ambito, il tipo e altre informazioni sono facilmente ottenibili dall'IDE. Quindi non è più necessario comunicare nulla di ciò in un prefisso.

In questi giorni è più importante che un programmatore sia in grado di trovare il tuo simbolo nella lista intellisense. E se metti un trattino basso prima, non può, perché verrà ordinato separatamente.

Un campo di supporto dovrebbe essere in camelCase senza trattini bassi. La proprietà corrispondente deve essere in PascalCase. In questo modo sono l'uno accanto all'altro nell'intelligenza, e il programmatore può vederlo immediatamente.