I prefissi per tipo e ambito sono utili convenzioni di denominazione?

Joel Spolsky ha scritto un articolo sul motivo per cui la notazione ungherese esiste e a cosa è destinata potrebbe aiutare a rispondere alle tue domanda.

I prefissi come tbl per una tabella di database, int per un intero, ecc. in genere non sono utili - è banale capire cosa è cosa dal contesto o dai tuoi strumenti di sviluppo in questi casi. Qualcosa di simile a un imp per misurazioni imperiali e incontrato per metrica ha molto più senso perché altrimenti puoi solo vedere che sono numeri in virgola mobile.

area = width * height

sembra perfettamente a posto mentre

impArea = metWidth * impHeight

ti mostra subito che qualcosa non va.

Personalmente uso solo nomi di variabili descrittive. $ number_of_items è ovviamente un conteggio intero. $ input_file_handle, $ is_active e $ encrypted_password hanno tipi ovvi sia in termini di tipo di dati di lingua che di tipo semantico.

Quello che stai descrivendo si chiama Notazione ungherese . Un tempo era considerato una buona pratica, ma in genere è disapprovato ora.

L'articolo di Wikipedia contiene una sezione sui suoi pro e contro.

Sì, i prefissi possono essere utili, ma ho un paio di suggerimenti:

Se tutta la squadra usa le stesse convenzioni, diventa molto più utile. Usarli da soli è meno utile.

In lingue strongmente tipizzate in modo statico, non copiare semplicemente il tipo di una variabile. Per esempio. "bSubscribed" è un brutto nome per una variabile booleana in C # o Java, perché il tuo IDE sa già di che tipo si tratta. In C d'altra parte, che manca di un tipo booleano, questa sarebbe un'informazione utile.

In C # e Java, potresti considerare un prefisso per mostrare che un oggetto può essere nullo. O che una stringa è stata salvata in html. O che rappresenta un'espressione regolare o un'istruzione sql. O che un array è stato ordinato. Usa la tua immaginazione.

Fondamentalmente è una questione di chiedersi cosa vorresti fosse un nome di variabile per dirti, e questo dipende molto dal dominio e dalla lingua in cui stai lavorando.

Ci sono alcuni diversi "stili" di convenzione sui nomi, e molti di essi hanno un certo valore nel rendere il codice comprensibile.

L'aspetto più importante della FAR è: utilizzare nomi descrittivi per variabili e funzioni. Nel tuo esempio con "somma", "peso" e "valore", potresti voler dare nomi più significativi: "totalCost", "lumberWeight", "lumberValuePerOunce" (sto facendo alcune ipotesi qui)

Trovo che le convenzioni come i nomi di variabili in sospeso con un carattere che indicano il tipo siano piuttosto fastidiose nella maggior parte delle lingue moderne.

Molti sviluppatori .NET seguono le linee guida sulla progettazione di Microsoft ( link ), che è molto simile a Java (la differenza principale è Microsoft favorisce Pascal Case per i nomi dei membri , mentre Java preferisce Camel Case).

A parte questo, direi che il codice di esempio è molto meno leggibile a causa del rumore extra che hai aggiunto.

Trovo che, per la maggior parte, la guida allo stile di codifica di Google sia abbastanza buono. Dal momento che ti è stato detto che puoi usare qualsiasi stile che ti piace, penso che dovresti iniziare osservandolo e scegliendolo da esso.

Il prefisso dei nomi delle variabili con tipi di dati (specialmente i tipi di dati primitivi) aumenta il rumore visivo, oltre al rischio che un piccolo cambiamento diventi una ridenominazione big-bang.

Per quanto riguarda il primo punto, "intStudentCount" è davvero più chiaro di ad es. "numero di studenti"? "InvoiceLineItems" non sarebbe almeno tanto informativo quanto "aobjItems". (Il tipo di dati dovrebbe riguardare il significato dei dati nel dominio del problema, non la rappresentazione di basso livello.)

Per quanto riguarda il secondo punto, cosa succede quando ad es. una selezione prematura di int è sostituita da lunga o doppia? Ancora peggio, cosa succede quando una classe concreta viene refactored in un'interfaccia con più classi di implementazione? Ogni pratica che aumenta l'onere degli scenari di manutenzione realistica mi sembra discutibile.

Potrebbe dipendere anche da perché stai anteponendo il nome, al contrario di ciò che lo hai prefisso.

Ad esempio, tendo a utilizzare un prefisso di 1-2 lettere per i nomi dei controlli su un modulo. Non è perché non so che il compilatore troverà facilmente la classe giusta per il pulsante (come un esempio), ma tendo a progettare prima le forme grandi, quindi scrivere la maggior parte del codice in seguito.

Avere un prefisso bt per i pulsanti consente di trovare facilmente il pulsante giusto in seguito, invece di avere molti nomi mescolati insieme.

Non uso prefissi per le variabili di denominazione, né per il tipo (che in genere non è altrettanto utile), né per il significato, il contesto o l'unità (che è l'idea originale alla base della notazione ungherese).

A mio avviso, dipende dalla lingua e dalle dimensioni del progetto. Non sono mai arrivato al punto di usare i prefissi di tipo su tutte le mie variabili, ma tu vuoi chiamarli in modo chiaro.

In un linguaggio tipizzato staticamente, come quello che stai utilizzando, più mi sento a mio agio con il sistema di tipi, meno importante diventa la notazione ungherese. Quindi in Java o C # e soprattutto in Haskell non penserei nemmeno di aggiungere quei prefissi, perché i tuoi strumenti possono dirti il tipo di ogni espressione data, e cattureranno la maggior parte degli errori derivanti da un malinteso di un tipo.

I prefissi spesso hanno senso per gli oggetti, ad esempio in un modulo in cui potresti avere 20 caselle di testo che chiamano tutto tbSomething ha senso.

Tuttavia, per lo più non penso che valga la pena, specialmente per i tipi di valore.

Ad esempio, supponiamo di avere:

short shortValue = 0;
//stuff happens

Mesi dopo trovi che devi cambiarlo - un corto non è abbastanza grande. Ora hai:

int shortValue = 0;
//stuff happens

A meno che tu non modifichi anche il nome della variabile (più rischio di violare il codice che modificare il tipo in questo caso) ora hai un codice confuso.

È meglio avere un nome che descriva cosa contiene:

int loopCounter = 0;
//stuff happens

Se in seguito sarà necessario passare a un intervallo lungo: nessun problema.

C'è forse più argomento per queste convenzioni in lingue digitate dinamicamente o in quelle senza IDE.

Sono sempre stato incline ad usare un'abbreviazione da 2 a 4 caratteri per il tipo di fronte alla variabile stessa. A volte sembra noioso, ma quando lavori con tipi di dati o situazioni complessi, diventa utile. Penso che cada nella categoria dei cammelli inferiori.

Guardando il tuo esempio sopra, sarebbe leggermente riorganizzato essere:

int intTickCount;
bool boolConnected;
object[] aobjItems;

Gli array hanno sempre un a davanti al tipo per designare la matrice. Questo mi consente anche di raggruppare istanze di variabili simili insieme. Ad esempio, posso usare ...

taStore.Fill(dtStore);

... che indica che il mio Store TableAdapter sta compilando lo Store DataTable.

Ho sempre cercato di aderire al principio di base che i prefissi e / oi suffissi devono essere inseriti solo quando rendono il codice più leggibile (come in inglese).

Meno è criptico, meglio è ...

Perché avere un metodo come questo:

public boolean connect( String h, int p );

Quando puoi avere qualcosa di simile:

public boolean connect( String hostName, int port );

Inoltre, gli IDE oggi hanno davvero un potente strumento per refactoring (specialmente Java) variabili, nomi di metodi, classi, ecc ... L'idea di dire che l'informazione massima con il minor numero di caratteri è solo antiquata.