Pubblicato nella Rubriki Numero 0 - 30 Nov 2005 da FabioCozzolino

Una delle linee guida più discusse è quella che prevede l’utilizzo dello US English come lingua per la scrittura degli identificatori. Dal libro di F.Balena e G. Dimauro "Microsoft.NET Framework. Regole di stile e best practice", regola 6.2: "Utilizzo dell'inglese americano per gli identificatori", "Utilizzare l'inglese per i nomi dei tipi e dei membri ed evitare di mischiare l'uso di inglese e italiano. Meglio ancora, utilizzare l'inglese americano, ad esempio scrivendo Color (inglese americano) invece di Colour (inglese)”. Il vantaggio, come spiegato nelle righe successive, è quello di realizzare un codice omogeneo poiché costituito da nomi simili a quelli utilizzati dal framework, oltre a garantire un maggiore accostamento alle impostazioni dei numerosi tool in circolazione come FxCop.

Tuttavia alcuni considerano il codice poco leggibile e per questo preferiscono una nomenclatura totalmente localizzata (in italiano) o, in alcuni casi, mista, dove le Data Entity/Business Object sono in italiano, e tutto il resto è espresso in inglese americano, consentendo una comprensione più immediata dell’entità. Un esempio di funzione di lettura del cliente verrebbe espressa così:

• Modo 1 (US English): ReadCustomer;
• Modo 2 (Italiano): LeggiCliente;
• Modo 3 (Misto): ReadCliente;

Il discorso è leggermente diverso per quello che riguarda i commenti. Sempre dal libro di Balena-Dimauro, regola "3.2. Linguaggio utilizzato per i commenti": "Utilizzare una unica lingua per i commenti, evitando di mischiare italiano e inglese”. La motivazione è semplice: utilizzo semplificato di tool per il controllo ortografico. Se non condizionati dall’uso di una lingua specifica (es.: il codice sviluppato per il mercato internazionale è condizionato all’uso dell’inglese), la scelta di una o dell’altra lingua è quasi indifferente.

Dalla discussione sono emersi diversi pro e contro di ogni metodo che proviamo a schematizzare qui:

• Modo 1 (US English)
• Pro
• Somiglianza con gli identificatori utilizzati nel .NET Framework
• L'uso di particolari suffissi (come Base per le classi base e Collection per le classi di tipo collection) ha senso solo se si utilizza la lingua inglese per gli identificativi
• Omogeneità con i termini che si trovano sui libri, sui siti e sulla documentazione ufficiale
• Una buona occasione per imparare l'inglese
• E' quasi d'obbligo quando si progetta l'interfaccia di una libreria distribuibile
• Quando si usa un linguaggio che permettere di creare un DSL (Domain Specific Language) usare l'inglese è un "must"
• Nomi molto più brevi e concisi
• Rispetta eventuali evoluzioni del software che stiamo programmando verso scenari probabilmente non considerati, come il mercato internazionale
• Contro
• La scelta di un nome semplice, intuitivo ed inequivocabile potrebbe essere più difficoltosa dall'uso di una lingua straniera
• Modo 2 (Italiano)
• Pro
• Codice più leggibile ed intuitivo
• Semplicità nella scelta dei termini più adatti
• Minore probabilità di collisione tra i nomi (anche se l'uso di namespace potenzialmente riduce questo problema)
• Lavorare con entità/oggetti/tabelle chiamate "Cliente" rende molto più l'idea rispetto ad entità/oggetti/tabelle chiamate "Customer"
• L'analisi dei requisiti o le comunicazioni con il cliente sono facilitate
• Contro
• Difficoltà con l'uso di tool per il controllo ortografico come FxCop
• L'uso delle lettere accentate non è consentito dalle regole di naming
• Modo 3 (Misto)
• Pro
• La chiarezza e i vantaggi che ne conseguoni dall'uso dell'italiano per le entità/oggetti/tabelle
• Uso di termini convenzionali come read, write, get o set
• Contro
• Le modalità d'uso dell'inglese o dell'italiano non sempre sono chiare agli sviluppatori di un team, generando confusione nel caso di un utilizzo non corretto

Concludendo, la maggior parte degli sviluppatori intervenuti alla discussione preferiscono l’utilizzo dello “US English” come lingua da utilizzare per la definizione degli identificatori, mentre i commenti possono essere espressi in una delle due lingue, purchè la stessa utilizzata in tutta l'applicazione. E' emersa anche la necessità di definire, all’interno del team, quelle che sono le regole da seguire per la corretta scrittura del codice, alle quali ogni sviluppatore deve attenersi indipendetemente da quelle che sono le proprie preferenze personali.