Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Annotazioni
Questo contenuto viene ristampato con il permesso di Pearson Education, Inc. da Framework Design Guidelines: Conventions, Idioms e Pattern per Librerie .NET Riutilizzabili, 2a Edizione. 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.
La scelta delle parole
✔️ SCEGLI nomi di identificatori facili da leggere.
Ad esempio, una proprietà denominata HorizontalAlignment è più leggibile dall'inglese rispetto a AlignmentHorizontal.
✔️ Favorire la leggibilità rispetto alla brevità.
Il nome CanScrollHorizontally della proprietà è 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 di uno senza di esso.
Uso di abbreviazioni e acronimi
❌ NON usare abbreviazioni o contrazioni come parte dei nomi degli identificatori.
Ad esempio, usare GetWindow anziché GetWin.
❌ NON usare acronimi che non sono ampiamente accettati, e anche se sono, solo quando necessario.
Evitare i nomi Language-Specific
✔️ Usare nomi semanticamente interessanti anziché parole chiave specifiche della lingua per i nomi dei tipi.
Ad esempio, GetLength è un nome migliore di GetInt.
✔️ DO usa 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 longspecifico 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 |
| breve | breve | breve | Int16 |
| ushort | UInt16 | breve senza segno | UInt16 |
| Int | Intero | Int | Int32 |
| uint | UInt32 | unsigned int | UInt32 |
| lungo | lungo | __int64 | Int64 |
| ulong | UInt64 | __int64 senza segno | UInt64 |
| galleggiare | Singolo | galleggiare | Singolo |
| doppio | Doppio | doppio | Doppio |
| Bool | Booleano | Bool | Booleano |
| Char | Char | wchar_t | Char |
| stringa | Stringa | Stringa | Stringa |
| oggetto | 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.
✔️ DO preferisce aggiungere un suffisso anziché un prefisso per indicare una nuova versione di un'API esistente.
Questo aiuterà la scoperta 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.
✔️ DO usa 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.
✔️ DO usa il suffisso "64" quando 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.
© Porzioni 2005, 2009 Microsoft Corporation. Tutti i diritti riservati.
Ristampato dall'autorizzazione di Pearson Education, Inc. da Framework Design Guidelines: Conventions, Idioms e Patterns for Reusable .NET Libraries, 2nd Edition di Krzysztof Cwalina e Brad Abrams, pubblicato il 22 ottobre 2008 da Addison-Wesley Professional come parte della Serie di sviluppo di Microsoft Windows.