Analyze machine-generated code (model-based / Simulink)¶
Model-based toolchains (Simulink/Embedded Coder and similar) emit large volumes of C/C++ that no one wrote by hand: long generated names, heavy macro use, and files that are regenerated wholesale on every model change. Understand analyzes it fine — the trick is deciding how much of it you want in view and keeping the project current as the generator reruns.
1. Decide what to include¶
The first question is whether the generated code is the subject of analysis or just context:
- Analyzing the generated code (reviewing what the model produced, tracing flow through it) — add it like any source.
- Analyzing hand code that sits beside it — keep the generated trees out of your metrics and graphs so they don't swamp the parts you own. Use file filters to include or exclude directories — see Manage your project's files.
Separate generated from hand-written
Even when you include both, it helps to put generated output in its own architecture node so you can look at hand code and generated code separately and keep metric rollups honest.
2. Cut through the volume¶
Generated code is big and repetitive, so lead with the views that summarize:
- Where is my risky / complex code? — the Treemap/Heatmap find the few units worth reading in a sea of boilerplate.
- Graphs (call trees, control flow) let you follow the actual logic instead of scrolling generated files — see the graph catalog.
3. Keep it current when the model regenerates¶
Because the generator overwrites files on every model change, your analysis goes stale quickly. Make re-analysis part of the loop — see Keep your analysis up to date, and script it headlessly in CI so a regenerated model produces a fresh database automatically.
Where to next¶
- Manage your project's files — include/exclude the generated trees.
- Per-language accuracy notes.