Most people use Visual Assist to get around a codebase and refactor safely. But there’s a whole set of checks and one-click fixes, just one checkbox away, that most users don’t know about—Code Inspections.
Code Inspections looks over your code while you work and points out anything that could cause trouble later. Some checks make code easier to read, some bring it up to modern C++, and some catch problems you’d definitely want to know about before they reach a customer.
Code Inspections used to be off by default, which is why many users have never seen it. From 2026.5, Visual Assist asks what you want to do when you open a solution (see step 1 below). You can also switch it on any time in VAssistX → Visual Assist Options → Code Inspection.
Treat it as a second pair of eyes that never gets tired. Your own team’s code review will catch a lot, but reviewers are people. Whether we like to admit it or not, we’re bound to miss a few—especially in huge projects. By the fortieth file in a pull request, a NULL here or a moved-from string there slips right past us. But not past a parser. Inspections read every line the same way, every time.
The Visual Assist 2026.5 release is the perfect time to try it, since inspections can now cover your whole solution instead of just one file at a time. Here are the issues it catches, and how to switch them on without drowning your project in warnings.
Code Inspections underlines the issue and explains it when you hover.
What Code Inspections catches
Every example below uses a real check from Visual Assist’s Combined checker set (the one we recommend in step 3). You can look each one up by name in the clang-tidy documentation.
It catches bugs that compile cleanly
The best reason to turn inspections on is when you have code that builds fine but still does the wrong thing (i.e. the syntax is sound, but the logic is not.)
std::string name = GetPlayerName();
roster.push_back(std::move(name));
Log("Added " + name); // name was moved from
After std::move, name is still a valid string, but you can’t count on what’s in it. In practice it’s usually empty, so the log line prints just “Added”. The use-after-move check (bugprone-use-after-move) flags it.
int hits = 3; int shots = 4; double accuracy = hits / shots; // 0.0, not 0.75
Both values are integers, so the division drops the fraction before the result ever reaches the double. The integer-division check (bugprone-integer-division) catches it. Neither bug stops the build, and both are easy to miss in review.
It makes your code safer and more secure
There are a variety of checks available within Code Inspections. Some are about convention, like keeping a consistent style. Others are about correctness and safety: making code harder to misuse, catching memory errors, and keeping types from silently changing under you.
VA gives every check a default level, from 1 (critical) to 5 (a gentle notice), so you can see at a glance how serious a finding is. Most readability checks sit at level 5. About two-thirds of the C++ Safety checks sit at level 2, one step below critical.
Many of the safety checks come from two well-known rulebooks: the C++ Core Guidelines, edited by Ccreator Bjarne Stroustrup and Herb Sutter, and the [CERT C Coding Standard](https://cmu-sei.github.io/secure-coding-standards/sei-cert-cpp-coding-standard/), a secure-coding standard from Carnegie Mellon’s Software Engineering Institute. Here are three of them.
Texture* tex = new Texture(); delete tex; tex->Bind(); // using memory that's already been freed
This is a classic memory-safety bug: using memory after it’s been freed. Clang’s built-in bug finder, the static analyzer, flags it with its new/delete check (clang-analyzer-cplusplus.NewDelete). It’s bugs like this that matter beyond crashes found while testing. Microsoft has reported that around 70% of the vulnerabilities it assigns a CVE each year are memory safety issues.
void SetVolume(int percent); double level = 0.755 * 100; SetVolume(level); // 75.5 silently becomes 75
This one breaks the “don’t silently lose data” rule from the C++ Core Guidelines (rule ES.46, check cppcoreguidelines-narrowing-conversions). The decimal part disappears without a word. If cutting it off is what you want, writing static_cast<int>(level) tells the next reader that it was on purpose.
int sessionId = std::rand(); // predictable sequence
And this one breaks the smart random number rule from the CERT coding standard (rule MSC50-CPP, check cert-msc50-cpp). std::rand() makes no promises about how random its numbers are, and some versions repeat quickly enough to be predictable. For anything security-related, like session IDs or tokens, use a cryptographically secure generator.
We added the C++ Safety set in 2025.4, and our C+ safety checkers deep dive covers it in more detail.
Safety checks default to a more severe level than style checks, so the serious findings stand out.
It brings old code up to modern C++
A lot of the default checks come with a fix you can apply in one click. Here’s a small class before and after four of them.
// Before
class Texture : public Resource {
public:
virtual ~Texture(); // modernize-use-override
virtual void Load(); // modernize-use-override
Texture* next = NULL; // modernize-use-nullptr
};
std::unique_ptr<Texture> tex(new Texture()); // modernize-make-unique
for (size_t i = 0; i < textures.size(); ++i) // modernize-loop-convert
textures[i].Load();
// After
class Texture : public Resource {
public:
~Texture() override;
void Load() override;
Texture* next = nullptr;
};
std::unique_ptr<Texture> tex = std::make_unique<Texture>();
for (auto& texture : textures)
texture.Load();
Some fixes are mainly for cleaner code, but override also helps prevent bugs. If the base class’s Load() signature changes, the compiler flags the mismatch instead of letting your function become a separate method that never gets called.
One 2026.5 change you should know about is that the override check now covers destructors by default, like the ~Texture() line above. Destructors without override weren’t flagged before, so you may see a few new findings in code that looked clean.
It skips work your code doesn’t need to do
for (auto mesh : scene.meshes) // copies every Mesh
total += mesh.vertexCount;
// fix: for (const auto& mesh : scene.meshes)
The range-loop copy check (performance-for-range-copy) spots loops that copy each element when a reference would do.
It gives everyone the same answer
Inspections are rules. The same code gives the same findings on every run, on every machine, for every teammate. AI assistants are useful for exploring ideas, but their answers can vary from one prompt to the next. That makes them harder to rely on as a shared standard (which is why it’s often easier to run solo projects with AI).
For team leads, a shared checker set also means a shared definition of “clean.” Nobody needs to argue about typedef versus using in code review. The rule already settles it.
It stays out of your way, and it’s VA-integrated
The parser behind Code Inspections runs in a separate process from Visual Studio so it doesn’t drag down the editor’s performance. Fixes applied together in a file can also be undone in one step, so trying them is low-risk. And it’s already a part of Visual Assist. There’s nothing extra to purchase or install—just turn on Code Inspections and you’re good to go.
How to use Code Inspections across your solution
A few years back, users asked on our forum for a way to “run code inspections on all files”. VA 2026.5 delivers that with project-wide code inspections. Here’s the general approach you can use for your or your team’s projects.
Set your scope and rules once, and the inspections keep up as you code.
1. Turn it on for your solution
When you open a solution, Visual Assist asks: “Run project-wide code inspections for solution ‘…’?” Choose Enable, and tick Set as default for new solutions if you like.
Or start from Extensions → VAssistX → Code Inspection → VA Code Inspection Results. Results appear in the VA Project-Wide Code Inspection window.
The results window lives under Extensions → VAssistX → Code Inspection.
Visual Assist asks once per solution. Choose Enable to inspect the whole thing.
2. Pick the projects you work in
Choose All projects or Choose projects…. Protip: include only the projects you actually work in, because a narrower selection means faster inspections and a smaller database. You can always change the selection later on the Settings tab.
Start with the projects you touch every day. You can add more later.
3. Pick a checker set
In VA Options → Code Inspection → Checker Sets, you’ll find VA Default, C++ Safety, Combined and ProjectWide. For the editor, we recommend Combined, which joins the VA Default checks with the C++ Safety checks above. Project-wide scans use the ProjectWide set by default, so you can tune what the whole-solution scan runs without changing the checks you see as you edit. Checks with options show a gear icon on the Checker Sets screen; click it to adjust them.
The default sets are the ones we’ve tested and tuned. If you want more, you can switch on more of VA’s clang-tidy-based checks too, for 390+ checks in all.
Pick a ready-made set, or customize one check at a time.
4. Sort before you fix
The first scan of an older codebase can flag a lot of issues. It’s years’ worth of code being run through a rule set for the first time.
To make the list easier to work through, use the Checkers, Projects and Files filters and sort by level. Results stream in with your current files first, so you can start reviewing even before the scan finishes.
Our suggestion is to start with the auto-fixable modernize checks for a quick, low-risk win, then work through the level 2 findings by hand.
Findings stream in while the scan runs, so you can start sorting right away.
5. Fix one, a whole file, or everything
In the editor, put the caret on an issue and press Shift+Alt+Q for the quick fix. In the inspection window, right-click a finding for Apply Selected Quick Fix, Apply All Quick Fixes in ” or Apply All Quick Fixes.
Some checks, like use-after-move, flag a problem without offering a fix. Those deserve a human decision anyway.
Press Shift+Alt+Q on an issue to apply its fix right in the editor.
Apply one fix, every fix in a file, or every fix in the solution.
One command applied every available fix in the file.
6. Turn off the rules you don’t want
Not every team wants to enforce every rule. For example, if you’d rather keep your typedefs, you can silence the typedef-to-using check (modernize-use-using).
From the right-click menu, you can suppress a check in one file, one project or the whole solution, and manage them all on the Suppressions tab.
You can also suppress it in code. VA honors clang-tidy’s NOLINT comments, so code already set up for clang-tidy carries over properly:
// NOLINTNEXTLINE(modernize-use-using) typedef std::map<int, Entity*> EntityMap;
VA’s own vaCI:skip directives work too, for a line, a range or a whole file. Put simply, you decide which rules count for your code, and the rest stay quiet.
Every suppression lives in one place, so it’s easy to undo later.
7. Leave it running
From here, inspections keep up as you edit and reparse only what changed. This means you can clear the backlog once, and the list will stay short as you add new code.
Get a second pair of eyes on your whole solution
Reviewers get tired; inspections don’t. If you already use Visual Assist, update to 2026.5 and click Enable when it asks. It’s often a surprise to see what turns up in code you thought was already clean. We think you’ll be glad you did.
Tell us which checks you want next, or what tripped you up, on our Discord. Our team appreciates the feedback and uses it to grow the inspection set.
New to Visual Assist? You can try all of this free for 30 days.
FAQ
Is Code Inspections the same as clang-tidy?
Not exactly. It’s built on LLVM’s clang-tidy checks and runs inside Visual Studio, with quick fixes, levels and suppressions on top.
Is Code Inspections AI?
No. It’s rule-based, so the same code always gives the same findings.
Will it slow down Visual Studio?
It’s designed not to. The parser runs in a separate process. For an even lighter load, inspect fewer projects or turn off automatic reparsing.
Why don’t some issues show up?
In the per-file inspection, third-party directories are skipped by default (project-wide scans include them). A compile error also stops inspection at that point in the file, and some checks switch off when the project’s C++ standard is too old for their fix.
What does “Parsing failed!” mean?
It depends on where you see it. If the editor shows “Parsing failed!”, that comes from the per-file inspection: turn on VA logging and send support the VaCodeInspections.log file from your %TEMP% folder. For project-wide scans, open the Log tab and filter it to Warning to see which files failed. To find out why, right-click one of that file’s results, choose Collect Support Information, and send support the zip.
Which Visual Studio versions are supported?
Code Inspections works in Visual Studio 2010 and newer. Project-wide inspection needs Visual Studio 2015 or newer.