Condividi tramite

Convenzioni di denominazione generali

  • Articolo

Nota

Questo contenuto viene ristampato con l'autorizzazione di Pearson Education, Inc. da Framework Design Guidelines: Conventions, Idiomsn and Patterns for Reusable .NET Libraries, 2nd Edition. Tale edizione è stata pubblicata nel 2008 e il libro è stato completamente rivisto nella terza edizione. Alcune informazioni in questa pagina potrebbero non essere aggiornate.

In questa sezione vengono descritte le convenzioni di denominazione generali correlate alla scelta delle parole, alle linee guida sull'uso di abbreviazioni e acronimi e alle raccomandazioni su come evitare l'uso di nomi specifici della lingua.

Scelta parola

✔️ SCEGLIERE nomi degli identificatori che siano facilmente leggibili.

Ad esempio, una proprietà denominata HorizontalAlignment è più leggibile in inglese rispetto a AlignmentHorizontal.

✔️ Favorire la leggibilità rispetto alla brevità.

Il nome della proprietà CanScrollHorizontally è migliore di ScrollableX (un riferimento oscuro all'asse X).

❌ NON usare caratteri di sottolineatura, trattini o altri caratteri non alfanumerici.

❌ NON usare la notazione ungherese.

❌ EVITARE di usare identificatori in conflitto con parole chiave di linguaggi di programmazione ampiamente usati.

In base alla regola 4 di Common Language Specification (CLS), tutti i linguaggi conformi devono fornire un meccanismo che consenta l'accesso a elementi denominati che usano una parola chiave di tale linguaggio come identificatore. C#, ad esempio, usa il segno @ come meccanismo di escape in questo caso. Tuttavia, è comunque consigliabile evitare parole chiave comuni perché è molto più difficile usare un metodo con la sequenza di escape rispetto a uno senza di esso.

Uso di abbreviazioni e acronimi

❌ NON usare abbreviazioni o contrazioni come parte dei nomi degli identificatori.

Usare, ad esempio, GetWindow invece di GetWin.

❌ NON usare acronimi che non sono ampiamente accettati, e, anche se lo sono, solo quando necessario.

Evitare nomi specifici della lingua

✔️ USARE nomi semanticamente interessanti anziché parole chiave specifiche della lingua per i nomi dei tipi.

Ad esempio, GetLength è un nome migliore di GetInt.

✔️ USARE un nome di tipo CLR generico, anziché un nome specifico del linguaggio, nei rari casi in cui un identificatore non ha un significato semantico oltre il relativo tipo.

Ad esempio, un metodo che esegue la conversione in Int64 deve essere denominato ToInt64, non ToLong (perché Int64 è un nome CLR per l'alias long specifico di C#). La tabella seguente presenta diversi tipi di dati di base usando i nomi dei tipi CLR , nonché i nomi dei tipi corrispondenti per C#, Visual Basic e C++.

C# Visual Basic C++ CLR
sbyte SByte char SByte
byte Byte char senza segno Byte
short Short short Int16
ushort UInt16 short senza segno UInt16
int Integer int Int32
uint UInt32 unsigned int UInt32
long Long __int64 Int64
ulong UInt64 unsigned __int64 UInt64
float Singolo float Singolo
double Double double Double
bool Booleano bool Booleano
char Char wchar_t Char
string Stringa Stringa Stringa
object Oggetto Oggetto Oggetto

✔️ USARE un nome comune, ad esempio value o item, anziché ripetere il nome del tipo, nei rari casi in cui un identificatore non ha un significato semantico e il tipo del parametro non è importante.

Denominazione di nuove versioni delle API esistenti

✔️ Usare un nome simile all'API precedente durante la creazione di nuove versioni di un'API esistente.

Ciò consente di evidenziare la relazione tra le API.

✔️ PREFERIRE aggiungere un suffisso anziché un prefisso per indicare una nuova versione di un'API esistente.

In questo modo sarà utile l'individuazione durante l'esplorazione della documentazione o l'uso di IntelliSense. La versione precedente dell'API verrà organizzata vicino alle nuove API, perché la maggior parte dei browser e IntelliSense mostrano gli identificatori in ordine alfabetico.

✔️ PRENDERE IN CONSIDERAZIONE l'uso di un identificatore nuovo, ma significativo, anziché aggiungere un suffisso o un prefisso.

✔️ USARE un suffisso numerico per indicare una nuova versione di un'API esistente, in particolare se il nome esistente dell'API è l'unico nome appropriato (ad esempio, se è uno standard del settore) e se l'aggiunta di un suffisso significativo (o la modifica del nome) non è un'opzione appropriata.

❌ NON usare il suffisso "Ex" (o un suffisso simile) per un identificatore per distinguerlo da una versione precedente della stessa API.

✔️ USARE il suffisso "64" quando si introducono versioni delle API che operano su un intero a 64 bit (un numero intero lungo) anziché su un intero a 32 bit. È necessario adottare questo approccio solo quando esiste l'API a 32 bit esistente; non farlo per le nuove API con solo una versione a 64 bit.

Parti protette da copyright © 2005, 2009 Microsoft Corporation. Tutti i diritti sono riservati.

Ristampato con l'autorizzazione di Pearson Education, Inc. da Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, 2a edizione di Krzysztof Cwalina and Brad Abrams, pubblicato il 22 ottobre 2008 da Addison-Wesley Professional nella collana Microsoft Windows Development Series.

Vedi anche