{"id":5281,"date":"2026-10-30T20:05:01","date_gmt":"2026-10-31T00:05:01","guid":{"rendered":"https:\/\/www.wholetomato.com\/blog\/?p=5281"},"modified":"2026-10-30T20:29:50","modified_gmt":"2026-10-31T00:29:50","slug":"visual-assist-code-inspections","status":"publish","type":"post","link":"https:\/\/www.wholetomato.com\/blog\/visual-assist-code-inspections\/","title":{"rendered":"Why You Should Turn On Code Inspections in Visual Assist"},"content":{"rendered":"

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\u2014Code Inspections<\/strong>.<\/p>\n

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.<\/p>\n

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 \u2192 Visual Assist Options \u2192 Code Inspection.<\/p>\n

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\u2014especially in huge projects. By the fortieth file in a pull request, a NULL<\/code> 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<\/em>.<\/p>\n

The Visual Assist 2026.5 release<\/a><\/strong> 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.<\/p>\n

\"Visual<\/a>

Code Inspections underlines the issue and explains it when you hover.<\/p><\/div>\n

What Code Inspections catches<\/h2>\n

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<\/a>.<\/p>\n

It catches bugs that compile cleanly<\/h3>\n

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.)<\/p>\n

\n
std::string name = GetPlayerName();\r\nroster.push_back(std::move(name));\r\nLog(\"Added \" + name);   \/\/ name was moved from<\/pre>\n<\/div>\n
After std::move<\/code>, name<\/code> 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<\/code>) flags it.<\/p>\n
\n
int hits = 3;\r\nint shots = 4;\r\ndouble accuracy = hits \/ shots; \/\/ 0.0, not 0.75<\/pre>\n<\/div>\n
Both values are integers, so the division drops the fraction before the result ever reaches the double<\/code>. The integer-division check (bugprone-integer-division<\/code>) catches it. Neither bug stops the build, and both are easy to miss in review.<\/p>\n
It makes your code safer and more secure<\/h3>\n
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.<\/p>\n
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.<\/p>\n
Many of the safety checks come from two well-known rulebooks: the C++ Core Guidelines<\/a>, edited by Ccreator Bjarne Stroustrup and Herb Sutter, and the [CERT C<\/u> Coding Standard](https:\/\/cmu-sei.github.io\/secure-coding-standards\/sei-cert-cpp-coding-standard\/<\/a>), a secure-coding standard from Carnegie Mellon’s Software Engineering Institute. Here are three of them.<\/p>\n
\n
Texture* tex = new Texture();\r\ndelete tex;\r\ntex->Bind(); \/\/ using memory that's already been freed<\/pre>\n<\/div>\n
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<\/code>). 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<\/a>.<\/p>\n
\n
void SetVolume(int percent);\r\n\r\ndouble level = 0.755 * 100;\r\nSetVolume(level);   \/\/ 75.5 silently becomes 75<\/pre>\n<\/div>\n
This one breaks the “don’t silently lose data” rule from the C++ Core Guidelines (rule ES.46, check cppcoreguidelines-narrowing-conversions<\/code>). The decimal part disappears without a word. If cutting it off is what you want, writing static_cast<int>(level)<\/code> tells the next reader that it was on purpose.<\/p>\n
\n
int sessionId = std::rand();   \/\/ predictable sequence<\/pre>\n<\/div>\n
And this one breaks the smart random number rule from the CERT coding standard (rule MSC50-CPP<\/a>, check cert-msc50-cpp<\/code>). std::rand()<\/code> 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.<\/p>\n
We added the C++ Safety set in 2025.4, and our C+ safety checkers deep dive<\/a> covers it in more detail.<\/p>\n
\"Scale<\/a>
Safety checks default to a more severe level than style checks, so the serious findings stand out.<\/p><\/div>\n
It brings old code up to modern C++<\/h3>\n
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.<\/p>\n
 <\/p>\n
\n
\/\/ Before\r\nclass Texture : public Resource {\r\npublic:\r\n    virtual ~Texture();                         \/\/ modernize-use-override\r\n    virtual void Load();                        \/\/ modernize-use-override\r\n    Texture* next = NULL;                       \/\/ modernize-use-nullptr\r\n};\r\n\r\nstd::unique_ptr<Texture> tex(new Texture());    \/\/ modernize-make-unique\r\nfor (size_t i = 0; i < textures.size(); ++i)    \/\/ modernize-loop-convert\r\n    textures[i].Load();<\/pre>\n<\/div>\n
 <\/p>\n
\n
\/\/ After\r\nclass Texture : public Resource {\r\npublic:\r\n    ~Texture() override;\r\n    void Load() override;\r\n    Texture* next = nullptr;\r\n};\r\n\r\nstd::unique_ptr<Texture> tex = std::make_unique<Texture>();\r\nfor (auto& texture : textures)\r\n    texture.Load();<\/pre>\n<\/div>\n
Some fixes are mainly for cleaner code, but override<\/code> also helps prevent bugs. If the base class’s Load()<\/code> signature changes, the compiler flags the mismatch instead of letting your function become a separate method that never gets called.<\/p>\n
One 2026.5 change you should know about is that the override check now covers destructors by default, like the ~Texture()<\/code> line above. Destructors without override weren’t flagged before, so you may see a few new findings in code that looked clean.<\/p>\n
It skips work your code doesn’t need to do<\/h3>\n
\n
for (auto mesh : scene.meshes)   \/\/ copies every Mesh\r\n    total += mesh.vertexCount;\r\n\/\/ fix: for (const auto& mesh : scene.meshes)<\/pre>\n<\/div>\n
The range-loop copy check (performance-for-range-copy<\/code>) spots loops that copy each element when a reference would do.<\/p>\n
It gives everyone the same answer<\/h3>\n
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).<\/p>\n
For team leads, a shared checker set also means a shared definition of “clean.” Nobody needs to argue about typedef<\/code> versus using<\/code> in code review. The rule already settles it.<\/p>\n
It stays out of your way, and it’s VA-integrated<\/h3>\n
The parser behind Code Inspections runs in a separate process from Visual Studio<\/a> 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\u2014just turn on Code Inspections and you’re good to go.<\/p>\n
How to use Code Inspections across your solution<\/h2>\n
A few years back, users asked on our forum<\/a> 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.<\/p>\n
\"Diagram<\/a>
Set your scope and rules once, and the inspections keep up as you code.<\/p><\/div>\n
1. Turn it on for your solution<\/h3>\n
When you open a solution, Visual Assist asks: “Run project-wide code inspections for solution ‘\u2026’?”<\/em> Choose Enable<\/strong>, and tick Set as default for new solutions<\/strong> if you like.<\/p>\n
Or start from Extensions \u2192 VAssistX \u2192 Code Inspection \u2192 VA Code Inspection Results<\/strong>. Results appear in the VA Project-Wide Code Inspection<\/strong> window.<\/p>\n
\"Visual<\/a>
The results window lives under Extensions \u2192 VAssistX \u2192 Code Inspection.<\/p><\/div>\n
\"Visual<\/a>
Visual Assist asks once per solution. Choose Enable to inspect the whole thing.<\/p><\/div>\n
2. Pick the projects you work in<\/h3>\n
Choose All projects<\/strong> or Choose projects\u2026<\/strong>. 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<\/strong> tab.<\/p>\n
<\/div>\n
\"Visual<\/a>
Start with the projects you touch every day. You can add more later.<\/p><\/div>\n
3. Pick a checker set<\/h3>\n
In VA Options \u2192 Code Inspection \u2192 Checker Sets<\/strong>, you’ll find VA Default<\/strong>, C++ Safety<\/strong>, Combined<\/strong> and ProjectWide<\/strong>. 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.<\/p>\n
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.<\/p>\n
\"Visual<\/a>
Pick a ready-made set, or customize one check at a time.<\/p><\/div>\n
4. Sort before you fix<\/h3>\n
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.<\/p>\n
To make the list easier to work through, use the Checkers<\/strong>, Projects<\/strong> and Files<\/strong> filters and sort by level. Results stream in with your current files first, so you can start reviewing even before the scan finishes.<\/p>\n
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.<\/p>\n
\"VA<\/a>
Findings stream in while the scan runs, so you can start sorting right away.<\/p><\/div>\n
5. Fix one, a whole file, or everything<\/h3>\n
In the editor, put the caret on an issue and press Shift+Alt+Q<\/code> for the quick fix. In the inspection window, right-click a finding for Apply Selected Quick Fix<\/strong>, Apply All Quick Fixes in ”<\/strong> or Apply All Quick Fixes<\/strong>.<\/p>\n
Some checks, like use-after-move, flag a problem without offering a fix. Those deserve a human decision anyway.<\/p>\n
\"Visual<\/a>
Press Shift+Alt+Q on an issue to apply its fix right in the editor.<\/p><\/div>\n
\"Right-click<\/a>
Apply one fix, every fix in a file, or every fix in the solution.<\/p><\/div>\n
\"Alt<\/a>
One command applied every available fix in the file.<\/p><\/div>\n
6. Turn off the rules you don’t want<\/h3>\n
Not every team wants to enforce every rule. For example, if you’d rather keep your typedef<\/code>s, you can silence the typedef-to-using check (modernize-use-using<\/code>).<\/p>\n
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<\/strong> tab.<\/p>\n
You can also suppress it in code. VA honors clang-tidy’s NOLINT<\/code> comments, so code already set up for clang-tidy carries over properly:<\/p>\n
\n
\/\/ NOLINTNEXTLINE(modernize-use-using)\r\ntypedef std::map<int, Entity*> EntityMap;<\/pre>\n<\/div>\n
VA’s own vaCI:skip directives<\/a> 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.<\/p>\n
\"Suppressions<\/a>
Every suppression lives in one place, so it’s easy to undo later.<\/p><\/div>\n
7. Leave it running<\/h3>\n
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.<\/p>\n
Get a second pair of eyes on your whole solution<\/h2>\n
Reviewers get tired; inspections don’t. If you already use Visual Assist, update to 2026.5<\/a> and click Enable<\/strong> when it asks. It’s often a surprise to see what turns up in code you thought was already clean<\/em>. We think you’ll be glad you did.<\/p>\n
Tell us which checks you want next, or what tripped you up, on our Discord<\/a>. Our team appreciates the feedback and uses it to grow the inspection set.<\/p>\n
New to Visual Assist? You can try all of this free for 30 days.<\/p>\n
\r\n\t
Use code inspections to modernize and fix code issues.<\/h2>\r\n\t
VA uses clang-tidy checks to find and flag fixes in your codebase using a deterministic parser. Detect and apply fixes in bulk on your whole solution.<\/h4>\r\n\t
\r\n\t\tTry Visual Assist<\/a>\r\n\t<\/div>\r\n<\/div>\n
FAQ<\/h2>\n
Is Code Inspections the same as clang-tidy?<\/h3>\n
Not exactly. It’s built on LLVM’s clang-tidy checks and runs inside Visual Studio, with quick fixes, levels and suppressions on top.<\/p>\n
Is Code Inspections AI?<\/h3>\n
No. It’s rule-based, so the same code always gives the same findings.<\/p>\n
Will it slow down Visual Studio?<\/h3>\n
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.<\/p>\n
Why don’t some issues show up?<\/h3>\n
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.<\/p>\n
What does \u201cParsing failed!\u201d mean?<\/h3>\n
It depends on where you see it. If the editor shows \u201cParsing failed!\u201d, 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\u2019s results, choose Collect Support Information, and send support the zip.<\/p>\n
Which Visual Studio versions are supported?<\/h3>\n
Code Inspections works in Visual Studio 2010 and newer. Project-wide inspection needs Visual Studio 2015 or newer.<\/p>\n","protected":false},"excerpt":{"rendered":"
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\u2014Code Inspections. Code…<\/p>\n","protected":false},"author":213500340,"featured_media":5283,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_coblocks_attr":"","_coblocks_dimensions":"","_coblocks_responsive_height":"","_coblocks_accordion_ie_support":"","jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_newsletter_tier_id":0,"footnotes":"","jetpack_publicize_message":"","jetpack_is_tweetstorm":false,"jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":false,"jetpack_social_options":{"image_generator_settings":{"template":"highway","enabled":false}}},"categories":[672],"tags":[726360521,726360527,4458826,726360539,726360777],"class_list":["post-5281","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-tips-and-tricks","tag-c-safety","tag-clang-tidy","tag-code-inspection","tag-static-analysis","tag-visual-assist-2026-5"],"jetpack_publicize_connections":[],"aioseo_notices":[],"jetpack_featured_media_url":"https:\/\/i0.wp.com\/www.wholetomato.com\/blog\/wp-content\/uploads\/2026\/10\/00_code-inspections-header.png?fit=1672%2C941&ssl=1","jetpack_likes_enabled":true,"jetpack_sharing_enabled":true,"jetpack_shortlink":"https:\/\/wp.me\/pfpLS4-1nb","aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t