Lottando per non usare la notazione ungherese

Ho visto argomenti a favore e contro i sistemi ungheresi . Per alcuni anni ho lavorato su un progetto legacy che utilizza questo sistema nominando ogni variabile, funzionando con un prefisso del tipo di variabile ad es. (StrName, intAge, btnSubmit ecc.) (Conosco i prefissi delle app ungheresi originali per il tipo di variabile, non il tipo). Vorrei che il mio prossimo progetto lo abbandonasse completamente, ma trovo più difficile nominare cose simili in modo univoco senza ricorrere ad esso.

Diciamo che ho un modulo web per la raccolta di indirizzi e-mail e la loro memorizzazione in una tabella di database e un pulsante che chiama la funzione che salva l'indirizzo nel db.

Se sto usando la notazione in stile ungherese, potrei chiamare la casella txtEmailil pulsante btnEmaile il valore contenuto nella casella di testo strEmail. Potrei quindi utilizzare una funzione storeEmail(strEmail)per memorizzare l'e-mail. Ho una chiara convenzione qui, è ovvio quale sia ogni variabile.

Quale sarebbe la migliore pratica per nominare queste variabili

• senza ricorrere ai sistemi ungheresi,
• senza farli lunghi o confusi
• e con una chiara convenzione da utilizzare in tutto il mio progetto?

Il tuo ultimo punto è il più importante: qualunque cosa tu faccia, devi essere coerente nel tuo progetto e con i tuoi colleghi. Esistono due modi principali per ottenere coerenza e, se possibile, è necessario utilizzare entrambi. Innanzitutto usa 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 è avere revisioni tra pari di tutto il codice, in modo che tutti possano dare un'occhiata.

I tuoi altri due punti sembrano chiederti 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 rimodellare il tipo quando il sistema e gli strumenti del tipo erano un po ', diciamo, meno severi. Vale a dire se stavi programmando in C e passando i puntatori in giro l'unico modo per tenere traccia del tipo era usando l'ungherese. Ora, se stai usando un linguaggio come C # o Java non utilizzerai i puntatori (o molto raramente), quindi la necessità di qualsiasi tipo di ungherese scompare. Inoltre, gli IDE moderni ti consentono di vedere il tipo molto facilmente passando con il mouse sopra la variabile o, nel peggiore dei casi, usando una scorciatoia per vedere la dichiarazione originale. Quindi, non penso che tu abbia bisogno di alcun tipo di notazione, basta nominare la variabile in base a ciò che fa. Se si tratta di un indirizzo email, utilizza semplicemente "email" o "

Quando si ha a che fare con moduli Web / moduli Windows / altri elementi grafici, è logico utilizzare i sistemi ungheresi poiché è possibile avere controlli strettamente collegati tra loro, ad esempio una casella di testo e un'etichetta che vanno insieme; potresti nominarli txtEmaile lblEmaildistinguerli. Nella mia esperienza, questo è comune ed è effettivamente utile.

Ma nel tuo code-behind, questo tipo di denominazione non è necessario. Se si dispone di una variabile di tipo stringutilizzata per archiviare un'e-mail, basta nominarla email. Se, per qualche motivo, ti confondi, la maggior parte degli IDE dovrebbe permetterti di passarci sopra con il mouse e visualizzarne il tipo. (Idealmente, nelle cose OO, potrebbe essere un attributo di qualche oggetto, ed user.Emailè ancora più chiaro.)

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

Cosa rende una variabile "troppo lunga"?

Invece di txtEmail, btnEmailsi potrebbe usare UserEmailText, UserEmailButtone AdminEmailText,AdminEmailButton

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

AdminEmailIsValid inizia a delimitare su quanto tempo consentirei che la variabile sia.

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

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

Quindi è possibile creare un'istanza di una nuova variabile come classe e utilizzare la stessa notazione punto per accedere ai dati:

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

Ovviamente, questo è indirizzato ai linguaggi che usano il paradigma OOP, ma la maggior parte dei linguaggi di sviluppo web più diffusi sono orientati agli oggetti o consentono codici orientati agli oggetti (PHP, Python, C #, C ++, Java, JavaScript, ActionScript, ecc. ).