Linee guida nella scrittura di codice #01: Capitalization
Mercoledì 17 Ottobre 2007 - 10:29
di Gianni Malanga
Tutti noi sviluppatori sappiamo quanto sia importante scrivere il nostro codice in modo che sia facilmente leggibile ed interpretabile, per gli altri ma anche per noi stessi. Microsoft, a tal scopo, ha divulgato ormai da alcuni anni una serie di linee guida e buone pratiche che se seguite scrupolosamente permettono di raggiungere l’obiettivo di produrre codice leggibile e facile da mantenere.
Ma quanti conoscono realmente tutte queste regole e le applicano quotidianamente nel proprio lavoro? Con questo post volevo dare inizio ad una serie di “pillole” in cui riportare le linee guida più importanti, innanzitutto per portarle alla vostra attenzione ma anche per discuterne insieme la validità. Non dimentichiamoci infatti che nessuno ci obbliga a seguire queste regole e quindi, se qualcuno ha trovato difetti in alcune di esse, questa può essere l’occasione per discuterne insieme.
Iniziamo con una serie di convenzioni relative ai nomi, in particolare le regole di Capitalization, che sono:
- Pascal Case, prevede che la prima lettera del nome dell’identificativo e le prime lettere di ogni successiva parola concatenata vadano in maiuscolo, es: BackColor;
- Camel Case, prevede che la prima lettera dell’identificativo sia minuscola mentre le prime lettere delle successive parole concatenate siano maiuscole, es: backColor;
- Upper Case, tutte le lettere in maiuscolo, es: IO;
Nel caso in cui l’identificativo contenga più parole, Microsoft raccomanda di non utilizzare caratteri di separazione quali underscore (’_') o trattino (’-'), ma di lasciare semplicemente che l’alternanza delle lettere maiuscole e minuscole delle parole concatenate permetta di distinguerle.
Il Pascal Case è consigliato per tutti i membri pubblici, i tipi e i namespace mentre il Camel Case è consigliato per i nomi dei parametri.
Viene inoltre ribadito che non deve assolutamente essere utilizzato il case delle lettere per distinguere due identificativi in quanto non tutti i linguaggi di programmazione sono case sensitive e quindi si potrebbero avere problemi in caso di integrazione con altri linguaggi.
Categoria: Microsoft Dev | Permalink
Commenti
1
Ciao Gianni,
ottima idea!
Una domanda… nello specifico rispetto alle convenzioni suggerite come rientra il caso degli acronimi?Ad esempio Zen (PHP) consiglia di trattarli come termini normali, quindi c’è HttpClient e non HTTPClient.
Esattamente inverso Ruby dove esiste Net::HTTP e Net::HTTPClient e non viceversa. :)
# - postato da Simone Carletti - 17 Ottobre 2007 - 11:35
2
[OT]
Zend non Zen
[/OT]Nel caso di Zend si utilizza molto il Camel Case, sebbene non abbia trovato da nessuna parte una raccomandazione specifica (nemmeno in preparazione alla certificazione).
Io preferirei utilizzare la notazione tutta minuscola con le parole separate dall’underscore… anche se non lo faccio per evitare rogne con gli altri.
3
Ciao Simone,
approfitto della tua domanda per precisare due cose. Ho deliberatamente, in questo caso, lasciato fuori gli acronimi per due motivi. Primo perchè anche se a puntate, non sarebbe possibile per motivi di spazio affrontare tutte le guidelines e best practices di Microsoft (sono taaaante) e poi anche perchè lasciando fuori qualche argomento si stimola la discussione.Sugli acronimi il parere di Microsoft è un pò articolato. Innanzi tutto un acronimo dovrebbe essere utilizzato solo se sufficientemente noto e quindi non confondibile. Ad esempio HTML è ok mentre SEO lo è meno. Poi questi vengono suddivisi in acronimi brevi e lunghi.
I brevi sono tutti gli acronimi di soli due caratteri mentre tutti gli altri (più di due caratteri) sono considerati lunghi.
Gli acronimi brevi andrebbero sempre scritti in maiuscolo tranne nel caso questi siano all’inizio di un identificatore scritto in notazione Camel Case. Ad esempio DBRow se in Pascal case, dbRow se in Camel Case.
Anche gli acronimi lunghi nel Camel Case andrebbero scritti in minuscolo (httpClient) mentre in Pascal Case (a differenza degli acronimi brevi) va in maiuscolo solo la prima lettera (HttpClient).
# - postato da Gianni Malanga - 17 Ottobre 2007 - 12:59
4
Nel caso di Zend si utilizza molto il Camel Case, sebbene non abbia trovato da nessuna parte una raccomandazione specifica (nemmeno in preparazione alla certificazione).
Zend in generale non ho materiale, per quanto mi riguarda seguo il framework
http://framework.zend.com/manu.....ndard.html :)# - postato da Simone Carletti - 17 Ottobre 2007 - 14:34
5
In generale:
- PascalCase (non sapevo si chiamase così) per i nomi delle classi,
- camelCase per variabili, proprietà, funzioni e metodi,
- UPPERCASE per le costanti o le globali.Ho alcuni standard importanti nella stesura del codice, ovviamente presi con flessibilità e variati in casi di necessità particolari. Lo faccio per non chiedermi tutte le volte, ma qui cosa volevo dire ?. Eccone alcuni:
- l’indentazione (4 spazi - no tab, ho avuto brutte esperienze con l’interpretazione della lunghezza dei tab),
- il posizionamento delle parentesi. L’aèertura sulla stessa riga del nome della funzione o della condizione e la chiusura a capo dell’ultima riga di istruzioni del blocco.
- “_” davanti a variabili private o protette e alcune eccezioni come in SQL
- Almeno uno spazio tra variabile, numero etc ed operatore (ciccio = 0, var > 1)
- Se dichiaro il valore di più variabili su più linee cerco di allineare gli “=”
- Nessuno spazio tra nome funzione e ()
- Gli argomenti di una funzione con valore di default vengono prima di quelli senza (nei linguaggi che lo supportano)
- Commenti simil Javadoc per classi e funzioni anche se non creo la documentazione, e soprattutto sovrabbondanza di commenti.Ultima cosa che non ritengo per nulla un opzione (soprattuto la secondo) è il nome delle variabili:
1 - che abbia un significato da cui si intuisca quel che contiene.
2 - O tutte in inglese o tutte in italiano, diversamente impazzisco io ed il tizio che non si ricorda mai se data è una data o un gruppo di dati…Ho visto che più o meno con qualche variazione, si adatta alle varie guide di stile che ho trovato in giro. L’importante comunque per me è avere l’abitudine a farlo ed una logica sempre uguale.
Yuri
6
Quoto Yuri che sembra seguire quasi in toto la filosofia ECMAScript :-)
unico appunto sconcertante:
Gli argomenti di una funzione con valore di default vengono prima di quelli senza (nei linguaggi che lo supportano)
perdonami Yuri ma così perdi completamente la comodità di avere la possibilità di usare argomenti con un default …. tu che fai, ogni volta se non hai il dato metti il valore di default mentre scrivi codice? Non ti sembra un’inutile ed enorme perdita di tempo? … a me, sinceramente, si!
Nei linguaggi che lo permettono inoltre si preferisce mettere valori con default in fondo anche per emulare un overload di metodo (arguments.length, func_num_args() e via dicendo) … oltre a dover scrivere continuamente valori di default ti trovi impossibilitato dal capire come sia stato chiamato il metodo (è stato specificato quel valore o no?) … il che è meno ambiguo di un if($arg[3] === null) … non trovi?
7
Se ci sono piu di 2 argomenti con un default a volte preferisco passare un array e fare qualche controllo all’interno delle funzioni
# - postato da Matteo Poile - 18 Ottobre 2007 - 17:44
8
Ho sbagliato a scrivere… faccio l’esatto contrario per le motivazioni che hai descritto…
Pardon. :D
Tra l’altro cerco di non mettere argomenti senza default se non voglio generare errori di proposito (intercettati) in caso di dimenticanza.
# - postato da Yuri Morini - 20 Ottobre 2007 - 20:47
9
@Yuri:
soprattutto sovrabbondanza di commenti
Non concordo. L’eccesso di commenti è una cosa inutile e fastidiosa, forse più della totale assenza degli stessi.
Devono essere evincibili direttamente dal codice sia il *cosa* che il *come* di un certo bocco di codice, senza dover ricorrere a commenti.
Esempio di commento sbagliato:
// increment i: i ;Ho estremizzato (ma nemmeno tanto: mi è capitato di leggere codice con commenti a questo livello) giusto per rendere l’idea di commento inutile e ridondante.
NOTA : se troviamo necessario un commento sul *come*, probabilmente è opportuno un refactoring del codice!
Gli unici commenti utili e necessari sono quelli che esprimono il *perchè*, la motivazione che sta dietro un certa implementazione (che non si può dedurre dal codice)
HTH
# - postato da Matteo - 23 Novembre 2007 - 12:22
10
S’è mangiato il “più più” dopo la “i” nello snippet…
# - postato da Matteo - 23 Novembre 2007 - 12:25