Lottando per non usare la notazione ungherese

Il tuo ultimo punto è il più importante: qualsiasi cosa tu abbia bisogno di essere coerente nel tuo progetto e con i tuoi colleghi. Ci sono due modi principali per raggiungere la coerenza e, se possibile, dovresti usare entrambi. In primo luogo utilizzare uno strumento per verificare le convenzioni di denominazione in fase di compilazione. Nel mondo .Net StyleCop sarebbe un buon esempio di tale strumento. Il secondo modo per ottenere coerenza consiste nell'avere recensioni da parte di tutti di codice, in modo che tutti possano tenere d'occhio.

I tuoi altri due punti sembrano chiedere di un'alternativa. Non sono sicuro che tu abbia bisogno di un'alternativa; il punto in cui l'ungherese non è più popolare è che era usato per descrivere il tipo quando il tipo di sistema e gli strumenti erano un po ', diciamo, meno rigidi. Cioè se si stava programmando in C e si passavano i puntatori in giro, l'unico modo per tenere traccia del tipo era usando ungherese. Ora, se stai usando un linguaggio come C # o Java, non utilizzerai puntatori (o molto raramente), quindi la necessità di qualsiasi tipo di ungherese scompare. Inoltre, i moderni IDE consentono di vedere il tipo molto facilmente passando con il mouse sopra la variabile o, nel peggiore dei casi, utilizzando una scorciatoia per vedere la dichiarazione originale. Quindi, non penso che tu abbia bisogno di alcun tipo di notazione, basta nominare la variabile con quello che fa. Se si tratta di un indirizzo e-mail, basta usare "email" o "indirizzo email". Se si tratta di un nome cliente, basta usare "customerName" ecc.

Quando si ha a che fare con moduli Web / moduli Windows / altri elementi grafici, ha senso utilizzare Sistemi ungheresi poiché è possibile avere controlli strettamente legati tra loro, ad esempio una casella di testo e un'etichetta che vanno insieme; potresti chiamarli txtEmail e lblEmail per distinguerli. Nella mia esperienza, questo è comune ed è in realtà utile.

Ma nel tuo code-behind, questo tipo di denominazione non è necessario. Se hai una variabile di tipo string che viene utilizzata per archiviare un'email, chiamala email . Se, per qualche motivo, ti confondi, la maggior parte degli IDE dovrebbe permetterti di passare con il mouse su di essa e vedere il suo tipo. (Idealmente, in roba OO, potrebbe essere un attributo di alcuni oggetti e user.Email è ancora più chiaro.)

Penso che se nel tuo codice hai dichiarato più di un oggetto che non è un controllo della GUI che potrebbe essere giustamente chiamato email , qualcosa è intrinsecamente sbagliato nel tuo progetto.

Che cosa rende una variabile "troppo lunga"?

Invece di txtEmail , btnEmail potresti usare UserEmailText , UserEmailButton e AdminEmailText , AdminEmailButton

Il problema con questo è che potresti iniziare a pensare che la variabile inizi a diventare lunga:

AdminEmailIsValid inizia a delimitare su quanto tempo permetterò alla variabile.

Inoltre, potresti iniziare a notare che stai riutilizzando un insieme di variabili e un insieme di operazioni su tali variabili. Questo è ciò che OOP è progettato per. Invece di un insieme di variabili, crea un oggetto generico:

class EmailForm
  var textBox, button, text
  function storeEmail()

Quindi puoi creare un'istanza di una nuova variabile come classe e utilizzare la stessa notazione a punti per accedere ai tuoi dati:

userEmailForm = new EmailForm(...data...)
adminEmailForm = new EmailForm(...different data...)
doSomething( userEmailForm.text )
doSomethingElse( adminEmailForm.text )

Naturalmente, questo è indirizzato verso linguaggi che usano il paradigma OOP, ma la maggior parte dei linguaggi di sviluppo web popolari sono orientati agli oggetti, o consentono il codice orientato agli oggetti (PHP, Python, C #, C ++, Java, JavaScript, ActionScript, ecc.)