Naming guidelines utili nella programmazione

naming-guidelines.png
Programmando in un team, prima o poi si sente l’esigenza di adottare uno standard nella nomenclatura delle entita’ su cui si lavora: codice all’interno dei sorgenti, tabelle, viste, report, file del progetto e molto altro. Inoltre, anche se non si è in team, abituarsi a leggere e scrivere codice che segue certe convenzioni largamente adottate, aiuta nel momento in cui ci si approccia a sorgenti altri o code snippet pubblicati sulla Rete che utilizzano quelle convenzioni.

La scelta di queste naming guidelines, o linee guida per la nomenclatura, puo’ seguire diverse filosofie di pensiero, ognuna con i propri pro e contro. Alcune direttive comunque, consigliate da grossi big del settore, raccolgono sicuramente piu’ proseliti rispetto alle altre.

Nell’MSDN Microsoft, ad esempio, si trova molto materiale a proposito. Consiglio la lettura delle Naming Guidelines per .Net Framework, che affronta molti argomenti come i capitalization styles, l’uso di maiuscole e minuscole (case sensitivity), scelta delle parole, abbreviazioni e tutta una serie di consigli per assegnare nomi a classi, tipi enum, array, proprieta’, eventi e molto altro. Se poi non si conoscono il CamelCase o il PascalCase, Wikipedia aiuta, come sempre. E pensare che una volta consigliavano l’Hungarian notation.

Da altre fonti, inoltre, arrivano diversi consigli:

Questo articolo aiuta a definire quali sono tutti i fattori necessari per creare un buono standard per i proprio sorgenti e progetti: Implementing a Source Code Standard: a necessity.

Per quanto riguarda invece il mondo dei database, le cose cambiano a secondo del prodotto da utilizzare. Sempre riferendosi a Microsoft, anche qui vengono consigliate precise convenzioni da seguire nell’assegnazione dei nomi all tabelle, agli indici, alle chiavi, ai campi, alle viste, alle store procedure e diversi altri elementi. Rimane grossomodo valido il principio del PascalCase, dell’evitare caratteri come _ @ # $, dell’uso di alcuni particolari prefissi autodescrittivi. Ci sono anche altri articoli che delineano questi coding standard.

IBM invece, per il suo DB2, propone delle regole meno feree, specificando quali caratteri non usare e la lunghezza massima dei nomi.

In conclusione, ad ognuno il suo e Google, come al solito, fornisce molti spunti interessanti per la scelta.

Leave a Reply