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

Di recente, iniziando il mio primo lavoro come sviluppatore di software, mi è stato un po 'gettato l'idea che non dovevo seguire alcuna convenzione di denominazione nel mio codice. Il codice scritto da gruppi che lavoravano su altri progetti più grandi seguiva le convenzioni di denominazione, ma da quando sono stato invitato a scrivere una nuova applicazione autonoma, la sensazione era che non avesse importanza. Era l'ultima delle mie preoccupazioni, quindi ho appena preso quella convenzione esistente e ho corso con essa.

int nTickCount  
bool bConnected  
object[] m_aItems  
fSum += fWeight * fValue  
class cManager  
enum etSystemStates  
etSystemStates eState   
cManager.cs

Ma vale davvero la pena? Trovo difficile giudicare l'effetto netto che seguire questo tipo di convenzione di denominazione ha sulla comprensione e il rilevamento degli errori, ma, visivamente , sembra un po 'brutto. Inoltre, avere ogni classe e file nel progetto chiamato cSomething sembra abbastanza semplice.

Non ho l'illusione che sia un grosso problema da remoto rispetto a cose che fanno una differenza ovvia, come gli algoritmi e le architetture che impieghi. Ma qualsiasi convenzione che influisce su ogni riga di codice che scrivo sembra che valga la pena farlo.

Cosa trovi la convenzione di denominazione più elegante ed efficace, se ne hai bisogno? Indica il tipo e / o l'ambito?

Joel Spolsky ha scritto un articolo sul perché esiste la notazione ungherese e su ciò a cui era destinata che potrebbe aiutare a rispondere alla tua domanda.

Prefissi come tbl per una tabella di database, int per un numero intero, ecc. Non sono generalmente utili - è banale capire cosa sia cosa dal contesto o dagli strumenti di sviluppo in quei casi. Qualcosa di simile a imp per misure imperiali e incontrato per metrica ha molto più senso perché altrimenti puoi vedere solo che sono numeri in virgola mobile.

area = width * height

sembra perfettamente bene mentre

impArea = metWidth * impHeight

ti mostra subito che qualcosa non va.

Personalmente uso solo nomi di variabili descrittivi. $ number_of_items è ovviamente un numero intero. $ input_file_handle, $ is_active e $crypted_password hanno tipi ovvi sia in termini di tipo di dati linguistici che di tipo semantico.

Quello che stai descrivendo si chiama notazione ungherese . Una volta era considerata la migliore pratica, ma ora è generalmente disapprovata.

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 l'intero team utilizza le stesse convenzioni, diventano molto più utili. Usarli da soli è meno utile.

In lingue fortemente tipicamente statiche, non limitarti a copiare il tipo di una variabile. Ad esempio "bSubscribed" è un brutto nome per una variabile booleana in C # o Java, perché il tuo IDE sa già di che tipo è. In C invece, che manca di un tipo booleano, questa sarebbe un'informazione utile.

In C # e Java, potresti considerare un prefisso per mostrare che un oggetto potrebbe 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 si tratta di chiederti cosa vorresti dire un nome variabile e questo dipende molto dal dominio e dalla lingua in cui stai lavorando.

Esistono alcuni "stili" diversi di convenzione di denominazione e la maggior parte di essi ha un certo valore nel rendere comprensibile il codice.

Ciò che è più importante è: usare nomi descrittivi per variabili e funzioni. Nel tuo esempio con "sum", "weight" e "value", potresti voler dare nomi più significativi: "totalCost", "lumberWeight", "lumberValuePerOunce" (sto facendo alcune ipotesi qui)

Trovo convenzioni come anteporre nomi di variabili con un carattere che indica che il tipo è abbastanza fonte di distrazione nella maggior parte delle lingue moderne.

La maggior parte degli sviluppatori .NET segue le Linee guida di progettazione di Microsoft ( http://msdn.microsoft.com/en-us/library/ms229042.aspx ), che è abbastanza simile a quelle di Java (la differenza principale è che Microsoft preferisce Pascal Case per i nomi dei membri, mentre Java favorisce il caso di cammello).

A parte questo, direi che il tuo esempio di codice è 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 buona. Dal momento che ti è stato detto che puoi usare qualsiasi stile che ti piace, penso che dovresti iniziare guardando questo, e sceglierlo e sceglierlo.

Il prefisso dei nomi delle variabili con tipi di dati (in particolare tipi di dati primitivi) aumenta il rumore visivo, nonché il rischio che una modifica altrimenti piccola diventi una ridenominazione del big bang.

Per quanto riguarda il primo punto, "intStudentCount" è davvero più chiaro di, ad esempio, "numberOfStudents"? "InvoiceLineItems" non sarebbe almeno informativo come "aobjItems". (Il tipo di dati dovrebbe riguardare il significato dei dati nel dominio problematico, non la rappresentazione di basso livello.)

Per quanto riguarda il secondo punto, cosa succede quando, ad esempio, una selezione prematura di int viene sostituita da long o double? Ancora peggio, cosa succede quando una classe concreta viene refactorizzata in un'interfaccia con più classi di implementazione? Qualsiasi pratica che aumenta l'onere di scenari realistici di manutenzione mi sembra discutibile.

Potrebbe anche dipendere dal motivo per cui stai prefissando il nome, al contrario di quello con cui lo prefissi.

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

Avere un prefisso di bt per i pulsanti rende facile trovare il tasto giusto in seguito, invece di avere un sacco di nomi confusi.

Non uso prefissi per la denominazione delle variabili, né per il tipo (che in genere non è comunque 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. In realtà non sono mai arrivato al punto di usare i prefissi di tipo su tutte le mie variabili, ma tu vuoi nominarli in modo chiaro.

In una lingua tipicamente statica, come quella che stai usando, più mi sento a mio agio con il sistema dei tipi, meno importante diventa la notazione ungherese. Quindi in Java o C # e specialmente in Haskell non penserei nemmeno di aggiungere quei prefissi, perché i tuoi strumenti possono dirti il ​​tipo di qualsiasi espressione data e colpiranno la maggior parte degli errori derivanti dall'incomprensione 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 li chiamano tutti hanno tbSomethingun senso.

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

Ad esempio, supponiamo di avere:

short shortValue = 0;
//stuff happens

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

int shortValue = 0;
//stuff happens

A meno che ora non cambi anche il nome della variabile (più rischio di rompere il codice che cambiare il tipo in questo caso) ora hai un codice confuso.

È meglio avere un nome che descriva ciò che contiene:

int loopCounter = 0;
//stuff happens

Se più tardi questo deve cambiare in un lungo: nessun problema.

C'è forse più argomento per queste convenzioni in linguaggi tipicamente dinamici o quelli senza un IDE.

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

Guardando il tuo esempio sopra, sarebbe leggermente riprogettato per essere:

int intTickCount;
bool boolConnected;
object[] aobjItems;

Le matrici hanno sempre una a davanti al tipo per designare la matrice. Questo mi permette anche di raggruppare insieme istanze di variabili simili. Ad esempio, posso usare ...

taStore.Fill(dtStore);

... che indica che il mio Store TableAdapter si sta compilando nella Store DataTable.

Ho sempre cercato di aderire al principio di base secondo cui prefissi e / o suffissi dovrebbero essere inseriti solo quando rendono il codice più leggibile (come in un inglese semplice).

Meno criptico, meglio è ...

Perché avere un metodo come questo:

public boolean connect( String h, int p );

Quando puoi avere qualcosa del genere:

public boolean connect( String hostName, int port );

Inoltre, gli IDE oggi hanno davvero un potente strumento per il refactoring (specialmente Java) di variabili, nomi di metodi, classi, ecc ... L'idea di dire la massima informazione con la minima quantità di carattere è solo vecchio stile.