Si può dimostrare la qualità oggettiva di un codice sorgente? Quando penso a questa domanda non posso fare a meno di associarla alla scena de “L’attimo Fuggente” (qui: https://www.youtube.com/watch?v=s81k8faP_6o) nel quale viene citato (e condannato) un metodo scientifico e matematico per valutare la qualità di una poesia.

Allo stesso modo gli sviluppatori hanno definito delle metriche il cui scopo è definire, in maniera formale, quando una porzione di codice è migliore di un’altra.  La cosa divertente è che ovviamente non c’è nulla di formale in queste metriche, per cui dibattiti e controversie sono lontane dall’essere risolte. C’è chi è convinto che una code-coverage del 99% sia migliore di una del 60%, c’è chi crede che una classe da 50 righe sia per forza migliore di una da 100.. ma c’è anche chi è religiosamente convinto del contrario.

La mia personale opinione è che l’unica valida misura della qualità del codice sorgente sia questa:

Esistono però casi in cui tenere sotto controllo la qualità generale del codice sorgente è utile e doveroso, specialmente quando il team inizia a diventare grande, in questo caso ci facciamo aiutare da tool come OCLint.

OCLint (qui: http://oclint.org) è un tool molto potente e versatile per l’analisi di codice C, C++ e Objective-C.

Il modo più semplice per utilizzarlo è però insieme ad un altro tool: xctool, iniziamo quindi con l’installazione di quest’ultimo.

XCTool

XCTool è un wrapper per xcodebuild che serve per compilare progetti Xcode via command line veramente utile e versatile. Potete installare XCTool sia tramite HomeBrew sia scaricando direttamente il progetto da github. Io ho preferito questa seconda soluzione perché mi da la possibilità di utilizzare la versione 0.2.4 mentre su homebrew siamo fermi alla 0.2.3

Una volta scaricato il progetto github per utilizzarlo basterà invocare il comando:

<path>/xctool/xctool.sh

Scaricate anche questo progetto Xcode di esempio e provate a compilarlo con XCTool digitando:

/<path>/xctool/xctool.sh -project "LearnOCLint.xcodeproj" -scheme "LearnOCLint" build

Il risultato dovrebbe essere simile a questo:

XCTool può generare un report in formato json che può essere poi interpretato da OCLint, basta specificarlo tramite l’apposito parametro:

/<path>/xctool/xctool.sh -project "LearnOCLint.xcodeproj" -scheme "LearnOCLint" -reporter json-compilation-database:compile_commands.json clean build

In questo caso al termine della compilazione dovreste trovare il file compile_commands.json direttamente nella root del progetto.

Da notare che ho anche aggiunto il comando “clean”, altrimenti il file json sarà vuoto.

OCLint

Anche in questo caso decidete voi come meglio installare questo tool, io ho preferito scaricare i binari dal sito e procedere all’installazione manuale. Trovate tutte le info qui: http://docs.oclint.org/en/dev/intro/installation.html

Per eseguire finalmente l’analisi digitate questo comando:

oclint-json-compilation-database -v oclint_args "-report-type html -o report.html -rc=LONG_LINE=120"; open report.html

• oclint_args: specifica i parametri che verranno passati ad OCLint
• report_type html: genera un report in formato html.
• -o report.html:  nome del file che verrà generato
• -rc=LONG_LINE=120: specifica un modificatore per una regola di default. Genera un warning se nel codice ci sono righe lunghe più di 120 caratteri.
• open report.html:  apre il report al termine del processo.

Ecco il report generato da un progetto Xcode vuoto. In questo caso sono già presenti 7 warning perché Apple inserisce nel file Appdelegate.m dei commenti che sono ben più lunghi di 120 caratteri.

Alcune metriche possono essere veramente utili, come NESTED_BLOCK_DEPTH che di default è impostata a 5 ma io setterei a 3.

Questo codice:

    int a, b, c, d, e;
    if (a) {
        if (b) {
            if (c) {
                if (d){
                    if (e) {
                        NSLog(@"do something");
                    }
                }
            }
        }
    }

Genera questo tipo di warning:

Il vero neo di questo tool è di generare spesso molto rumore, ad esempio qualche giorno fa analizzando un grosso progetto ho scoperto che un file mi dava complessità ciclomatica (…si, una di quelle metriche un po’ così…) 112 mentre il limite di default è 10. Analizzando il report ho scoperto che il file in questione fa parte di una libreria molto ben quotata per il parsing delle date in formato ISO8601. Quale dovrebbe essere allora il mio giudizio su quella classe?

Il mio consiglio è quello di fidarvi innanzitutto del vostro fiuto e della vostra esperienza perché non esistono termini matematici per definire quando un codice è migliore di un altro, e utilizzate tool come OCLint per verificare che lo standard aziendale sia rispettato perché alla fine è sempre questione di trade-off. (Kent Beck è ufficialmente il mio idolo dopo aver visto questi video)