Skip to content

Export & track metrics over time

Which entities get a metric depends entirely on the metric, not on a fixed list Understand maintains — the built-ins mostly target functions, files, classes, and architecture nodes, but a metric plugin can target any entity kind at all (an object, variable, macro, …). Check a metric's own page in the metrics catalog for exactly which kinds and languages it applies to. Once analysis is done you can export metrics to a spreadsheet, a static HTML report, or the terminal — and by keeping a comparison database you can see how each metric moved between two analyses.

Export from the GUI (Metrics Browser)

Open Metrics → Browse Metrics. Select any architecture node, file, or entity on the left to see its metrics on the right. From here you have several ways to save them:

The tree only auto-lists functions, files, classes, and modules

Right-click → Add to Architecture works on any entity — an object, variable, macro, parameter, anything — and once it's tagged, it becomes selectable here too, showing whatever metrics actually apply to it (including plugin metrics that target that kind).

You want Do this
A full per-entity CSV you can sort/filter Export Metrics icon → Export to CSV (or Metrics → Export Metrics)
The metrics for one entity, quickly Select rows and press Ctrl+C, or right-click → Copy Selected / Copy All, then paste
A CSV for selected architecture nodes Down-arrow next to Export Metrics → Export Selected Architectures to CSV
A one-page project summary in HTML Down-arrow next to Export Metrics → Export Selected Architectures to HTML
A browsable tree of per-node HTML pages Down-arrow next to Export Metrics → Export to HTML

The Export Metrics dialog

Export to CSV opens the Export Metrics dialog, which gives full control over the CSV:

  • Available Metrics / Metrics to Export — check the metrics to include and reorder them (use SELECT ALL to grab everything).
  • Save output to — the destination .csv file.
  • Show File Entity Name as — Short, Full, or Relative names.
  • Show Declared in File — add the file each entity is declared in.
  • Write Column Titles — add a header row.
  • Show Function Parameter Types — disambiguate overloaded functions.
  • Include Entity Unique Name to track changes over time — adds an Entity_Uniquename column so you can match the same entity across analyses even when names collide. Turn this on if you plan to diff CSVs yourself.

The CSV includes a row for any entity that has a value for at least one of the metrics you selected — in practice that's mostly functions, files, classes, and structures, since that's what the built-in metrics target, but a plugin metric that targets another kind (an object or variable, say) adds rows for those too. Architecture nodes never get a row here. The HTML exports include only count metrics and land in a <Project_name>_Metrics folder (open index.html).

Metrics in the Information Browser

The Information Browser has a Metrics node showing a few key metrics for the current entity — handy for a quick look without opening the browser.

Additional metric exports are available as interactive reports — see Document a project for a quick reference (Line Metrics, Average Metrics, Class Metrics, Complexity Metrics), or the reports catalog for the full list.

Export from the command line (und metrics)

The und metrics command produces the same data headlessly — ideal for CI. It uses the project's current metrics settings.

Licensing

und metrics requires the external-export capability of your license; without it the command exits with an error.

und metrics myProject.und
Writes one row per entity to the file named by the output_file setting. The default output filename is the project path with .und replaced by .csv (so myProject.und → myProject.csv).

und metrics -arch myArch myProject.und
One row per architecture node (and its children). Default filename <archname>_metrics.csv.

und metrics -html arch1 arch2 c:\out myProject.und
Emits a tree of HTML pages into a <project>_Metrics subdirectory. All architectures are included if none are named.

und metrics -summary myProject.und
und metrics -summary -csv myProject.und
Prints project totals (CountLine, CountDeclFile, CountDeclClass, CountDeclFunction, CountDeclSubprogram) as Name: value lines, or two CSV lines with -csv.

Choose which metrics and how they're formatted

The default and -arch exports honor the saved metrics settings. Change them with und settings:

# Set the exact metric list (order matters); "all" selects everything
und settings -metric "CountLine,CountLineCode,Cyclomatic,CountPath" myProject.und
und settings -metricadd MaxNesting myProject.und
und settings -metricoutputfile results.csv myProject.und
und settings -metricwritecolumntitles on myProject.und
und settings -metricadduniquenamecolumn on myProject.und

View the current settings with und list -metrics settings myProject.und. See Configure settings & filter files for the settings workflow.

Want every metric in the CSV?

Add them to the saved list rather than hand-picking: und list -metrics settings myProject.und prints every metric available for the project, and -metricadd appends to the list without replacing it. Turn on -metricwritecolumntitles and -metricadduniquenamecolumn so the CSV is self-describing.

Track metrics over time

Understand tracks change through a comparison database — a second .und (typically an earlier analysis or a Git baseline) that the current project is compared against. Point at it with settings:

und settings -comparisonprojectpath baseline.und myProject.und

Then export the changed entities with und export -changes, which writes a CSV of how each entity moved between the two databases:

und export -changes -columns "Status,Long Name,PercentChanged" -kinds "file" \
  -cmpdb baseline.und myProject.und changes.csv
  • -cmpdb — the database to compare against (overrides the saved comparison database).
  • -kinds — limit to entities of a kind (e.g. file, function).
  • -columns — any of Status, Name, Long Name, Unique Name, the kind columns, file-name columns, the change metrics CountLineNew / CountLineRemoved / CountLineChanged / PercentChanged, or any metric API name (Cyclomatic, CountLine, …). PercentChanged is (added + removed + 2·changed) / (current + previous lines).

The default column set already includes CountLineNew, CountLineRemoved, CountLineChanged, PercentChanged, CountLine, CountLineCode, CountPath, Cyclomatic, and SumCyclomatic.

Simplest long-term tracking

Run und metrics on every build and archive the CSVs — for example one per tag or per nightly run — then chart the columns you care about in your spreadsheet or CI dashboard. The Entity_Uniquename column lets you follow a single function across runs.

For the visual, project-wide view of where risk concentrates (Treemap and Heatmap), see Where is my risky / complex code?. For metric meanings, see Interpret key metrics and What does Cyclomatic Complexity mean?.