risorse | metriche C++

Metriche C++

Da tempo sto valutando l'idea di integrare il processo di build di un progetto C++ di qualche decina di migliaia di righe con una attività automatica di monitoraggio della «qualità» del codice sorgente. Ho dapprima introdotto un'analisi statica del codice, ad opera del programma gratuito open-source Cppcheck: avviato prima della fase di compilazione, causa l'interruzione della procedura di build nel caso abbia individuato uno o più errori. Vorrei raffinare quest'attività raccogliendo ora alcune metriche del codice, per far emergere potenziali criticità del progetto e individuare le aree che necessitano di refactoring. Se le misure raccolte vengono archiviate sistematicamente, risulterà semplice valutare a posteriori l'effetto delle modifiche.

L'individuazione di una metrica fuori tolleranza non causa l'interruzione della procedura di build. Scopo dell'integrazione à fissare nel tempo lo stato del codice – sfruttando la produzione di una nuova versione degli artefatti come «orologio» – per osservare l'andamento della qualità del codice all'evolversi del progetto.

Tra le varie possibilità, ho deciso di concentrarmi su CCCC e Source Monitor.

CCCC

CCCC è un programma open-source, gratuito e multi-piattaforma. Riconosce sorgenti ADA, C, C++ e Java. Ricava le seguenti metriche:

Metriche di progetto:

• Number of modules (NOM): i moduli sono generici contenitori di codice, come classi, file, …;
• Lines of code (LOC): numero di righe di codice, escluse quelle vuote e quelle di commento;
• Lines of comments (COM): numero di righe di commento;
• McCabe's Cyclomatic Complexity (MVG): complessità ciclomatica globale;
• Lines of code per line of comment (L_C): stima della densità dei commenti;
• Cyclomatic Complexity per line of comment (M_C): stima la quantità dei commenti rispetto alla complessità del codice;
• Information flow measure (IF4): stima della interdipendenza dei moduli – basato sul metodo Henry-Kafura.

Metriche di modulo:

Le metriche di modulo comprendono un sottoinsieme di quelle di progetto (LOC, COM, MVG, L_C, M_C), oltre alle seguenti, classificate per tipologia:

Object-oriented

• Weighted methods per class (WMC): la metrica è usata in due varianti: WMC1, attribuendo un peso unitario a tutti i metodi, conteggia tutti i metodi del modulo, mentre WMCv, attribuendo un peso nullo ai metodi privati, conteggia i soli metodi accessibili agli altri moduli;
• Depth of inheritance tree (DIT): indica la lunghezza della più lunga catena di derivazione;
• Number of children (NOC): numero di moduli che derivano dal modulo in esame;
• Coupling between objects (COB): numero di moduli accoppiati al modulo in esame, clienti o fornitori che siano;

Strutturali

• Fan-in (FI): numero di moduli che passano informazione al modulo in esame;
• Fan-out (FO): numero di moduli cui il modulo sotto esame passa informazione;
• Information flow measure (IF4): indice di complessità strutturale, calcolato come √(FI × FO).

Metriche di metodo:

Le metriche di metodo comprendono un sottoinsieme di quelle di progetto: LOC, COM, MVG, L_C, M_C.

Soglie

CCCC attribuisce ad ogni metrica una soglia di attenzione «media» e una «alta»; i dati raccolti sono etichettati come rientranti in un ambito di normalità, nella zona d'attenzione media o in quella alta conformemente ai valori assunti rispetto ai valori di soglia. In assenza di specifiche configurazioni, CCCC utilizza le seguenti soglie:

Integrazione

CCCC si attende di ricevere l'elenco dei file da analizzare sulla linea di comando o sullo stream di input. I risultati dell'analisi sono salvati in una directory ad hoc, di norma .cccc. Le metriche di progetto e di modulo si trovano nel file cccc.xml, mentre quelle di metodo sono raggruppate per modulo di appartenenza e salvate in un file dedicato. Lo script seguente di occupa di analizzare tutti i file presenti nelle cartelle passate sulla linea di comando:

rem cccc.cmd
@echo off

if "%1"=="" echo Usage: %~n0 source-folders && exit /b %ERROR%

set PROGRAMFILES32=%ProgramFiles(x86)%
if "%PROCESSOR_ARCHITECTURE%"=="x86" set PROGRAMFILES32=%ProgramFiles%

set CCCC="%PROGRAMFILES32%\CCCC\cccc.exe"

set FILE_LIST=%TEMP%\cccc.lst
echo. >nul 2>%FILE_LIST%

:loop
if "%1"=="" goto done
dir /s /b %1 >> %FILE_LIST%
shift
goto :loop

:done

set REPORT_FOLDER=.\.cccc
type %FILE_LIST% | %CCCC% --outdir=%REPORT_FOLDER% - >nul 2>&1
del /q %FILE_LIST% >nul 2>&1

rem TODO: time to analyze the report!

rd /q /s %REPORT_FOLDER% >nul 2>&1

Note

CCCC non è in grado di gestire distintamente moduli omonimi: classi con lo stesso nome, poste in namespace diversi, sono trattate come definizioni parziali di un'unico modulo.

Source Monitor

Source Monitor è un programma closed-source gratuito che gira su Windows. Riconosce sorgenti C, C++, C#, Delphi, HTML, Java, VB.NET e Visual Basic. La versione in prova, 3.4.0.283, limitatamente al C/C++, fornisce le seguenti metriche:

Metriche di file:

• lines: numero di linee di codice;
• statements: numero totale di comandi; il conteggio include anche alcune direttive (es. #include, #define e #undef), così come le istruzioni try/catch; non sono conteggiati i comandi all'interno delle direttive #else/#elif e il relativo #endif;
• percent branch statements: percentuale di comandi di salto rispetto alla totalità dei comandi (if, else, for, while, break, …); entrano nel conteggio anche le istruzioni try/catch;
• percent lines with comments: percentuale di linee di commento rispetto a lines;
• classes: numero di classi definite; un template conta come una classe;
• methods implemented per class: numero medio di metodi per classe;
• functions: numero di funzioni identificate;
• average statements per method: numero medio di comandi per metodo/funzione;
• maximum method or function complexity: complessità del metodo più complesso;
• calls: numero totale di chiamate a metodo o funzione;
• maximum block depth: massimo livello di annidamento raggiunto dal codice;
• average block depth: livello medio di annidamento del codice;
• average complexity: media aritmetica delle complessità dei metodi.

Metriche di metodo:

• complexity: complessità ciclomatica (approssimata);
• statements: numero di comandi che compongono il metodo;
• maximum block depth: massimo livello di annidamento del codice;
• calls: numero di chiamate di altri metodi o funzioni.

Source Monitor può archiviare le metriche raccolte in una sequenza di checkpoint; ciò consente di monitorare l'evoluzione del codice nel tempo.

L'analisi dei sorgenti avviene molto rapidamente: su un PC equipaggiato con una CPU quad-core a 3GHz e 8GB di RAM, si raggiungono velocità dell'ordine delle centinaia di migliaia di linee al secondo.

Soglie

Integrazione

Il programma è richiamabile da linea di comando; il manuale a corredo del programma illustra chiaramente questa modalità di invocazione. I risultati in questo caso vengono salvati a scelta in formato XML o CSV. L'integrazione di Source Monitor nella procedura di build avviene per mezzo di due file di supporto:

• source-monitor.cmd: è lo script che si occupa di avviare Source Monitor:

  rem source-monitor.cmd
  @echo off
  
  if "%1"=="" echo Usage: %~n0 project-name && exit /b %ERROR%
  
  set PROGRAMFILES32=%ProgramFiles(x86)%
  if "%PROCESSOR_ARCHITECTURE%"=="x86" set PROGRAMFILES32=%ProgramFiles%
  
  set SOURCEMONITOR="%PROGRAMFILES32%\SourceMonitor\SourceMonitor.exe"
  set SOURCEMONITOR_CMD="%~dp0\%1.xml"
  
  %SOURCEMONITOR% /S %SOURCEMONITOR_CMD%
  
  rem TODO: time to analyze the report!
  
  rem remove project file
  del /q %TEMP%\%1.smp 1> nul 2>&1
  

• my-project.xml: è il file di configurazione necessario a Source Monitor per stabilire come e su quali file operare:

    <sourcemonitor_commands>
      <log_all_to_console />
      <command>
        <project_file>%TEMP%\PROJECT.SMP</project_file>
        <project_language>C++</project_language>
        <modified_complexity>true</modified_complexity>
        <source_directory>SOURCES-DIRECTORY</source_directory>
        <source_subdirectory_list>
          <exclude_subdirectories>false</exclude_subdirectories>
          <source_subtree>include\</source_subtree>
          <source_subtree>sources\</source_subtree>
        </source_subdirectory_list>
        <parse_utf8_files>True</parse_utf8_files>
        <checkpoint_name>baseline</checkpoint_name>
        <show_measured_max_block_depth>True</show_measured_max_block_depth>
        <file_extensions>*.h,*.cpp</file_extensions>
        <include_subdirectories>true</include_subdirectories>
        <export>
          <export_file>%TEMP%\PROJECT-METRICS.XML</export_file>
          <export_type>1 (export project summary in XML format)</export_type>
          <export_option>3</export_option>
        </export>
      </command>
    </sourcemonitor_commands>
  

Note

Salta immediatamente agli occhi l'assenza di misure relative al grado di accoppiamento dei moduli.

I dati esportati non recano alcuna indicazione circa il rispetto delle soglie di attenzione, il che implica la necessità di un meccanismo di sogliatura esterno nel caso si desideri evidenziare le entità fuori norma.

Per ottenere le statistiche in formato CSV, è necessario comandare due esportazioni distinte, una per quelle di progetto, l'altra per quelle di metodo – il formato CSV non permette di ragguppare statistiche strutturalmente diverse all'interno dello stesso file.

Un ultimo aspetto da considerare è che, nella modalità interattiva, manca un meccanismo per individuare rapidamente le aree critiche: il programma fornisce, alla granularità del file, una rappresentazione grafica dei parametri rispetto ai limiti impostati, ma non fornisce alcun criterio di selezione dei file fuori tolleranza.

Pagina modificata il 27/05/2013