Scrivere un programma è come scrivere un testo (un libro): lo si fa per comunicare qualcosa e lo si fa usando la grammatica e la sintassi del linguaggio.
Questo significa che per dire la medesima cosa si possono usare parole, espressioni, idiomi differenti. Solitamente un autore ha il suo stile, esso può anche cambiare intenzionalmente da libro a libro, ma difficilmente cambia all’interno dello stesso libro.
Idem con il codice, ognuno di noi ha il proprio stile di programmazione dato dall’esperienza e dal diverso modo di pensare/di approciare il problema. Se questo, riferendosi ad un libro è un bene, avere programmi o peggio parti del medesimo programma scritte da autori diversi con stili diversi, può diventare un problema. E’ come avere un libro scritto da diversi autori ciascuno con il proprio stile: anche se particolare, sarebbe sicuramente di difficile lettura. La situazione è ancor più tragica in un software, dove l’analisi e la correzione di possibili errori obbliga a rileggere e modificare parti scritte da altri (e quindi con stili diversi).
Insomma senza dover uniformare completamente il modo di scrivere software, che sarebbe un po’ snaturare la bellezza di questa attività che molti paragonano ad un arte, si può cercare di condividere alcune scelte di stile. Queste scelte denominate anche convenzioni o “coding convention” sono, come detto, dettate da necessità sicuramente diverse da chi scrive un libro. Wikipedia elenca le seguenti:
Code conventions are important to programmers for a number of reasons:
- 80% of the lifetime cost of a piece of software goes to maintenance.
- Hardly any software is maintained for its whole life by the original author.
- Code conventions improve the readability of the software, allowing engineers to understand new code more quickly and thoroughly.
- If you ship your source code as a product, you need to make sure it is as well packaged and clean as any other product you create.
Noi nel nostro team abbiamo una serie di naming convention, che sono un sottoinsieme delle coding convention relativamente a come chiamare gli identificatori (variabili, procedure, ecc).
Io sto cercando di andare più in là e mi sono dotato di un tool che la stessa Microsoft usa per identificare le parti di codice che non aderiscono alle convenzioni stabilite negli anni. Tale tool si chiama guardacaso StyleCop.
Si tratta di un progetto open-source e lo si può trovare qui. Esso si integra in Visual Studio e lo si può eseguire e configurare facendo click-destro sulla finestre del Solution Explorer. Per ogni violazione di stile viene riportato un warning con la descrizione del problema.
Per coloro che usano ReSharper, un ottimo tool che aiuta nella stesura del codice, vi è anche un add-in che consente di eseguire l’analisi dello stile man mano che si scrive il codice.
Davvero degli utili tool per cercare di migliorare il “nostro” stile di bravi artisti scrittori di codice