GNU Global C/C++ .vscode Config Pack

There is no error message. That is the whole problem.

Open a .vscode/settings.json that a teammate committed six months ago and you will not find a red squiggle anywhere in it. The file is valid JSON. Every key is a real key. VS Code reads it top to bottom, accepts it, and then quietly does nothing with about a third of it.

Here is the one that costs the most hours:

{
  "editor.formatOnSave": true,
  "editor.defaultFormatter": "prettier"
}

An extension id is always publisher.extension, with a dot. prettier is not an id, it is a word. There is no extension it can ever match, so format-on-save runs, finds no formatter, and returns. Nobody is told. The team concludes that format-on-save is unreliable and turns it off.

The same shape repeats across the whole folder:

{
  "cwd": "${workspaceRoot}/build",
  "clangPath": "~/llvm/bin/clang",
  "intelliSenseMode": "gcc-x64",
  "cStandard": "c++17",
  "console": "internalConsole"
}

${workspaceRoot} is the deprecated name and newer releases resolve it inconsistently, so the path can come out empty and your task runs in the wrong folder. VS Code does not expand a leading tilde in JSON, so ~/llvm/bin/clang resolves to a literal folder called ~ and the setting does nothing at all. gcc-x64 is the pre-platform form of intelliSenseMode; the current values carry the platform first, linux-gcc-x64, and the old one falls back to a guess, so your defines and include search can differ from the compiler that actually builds. cStandard takes c11, c17, c23 - a C++ standard put there makes IntelliSense parse your headers under the wrong language rules. And internalConsole cannot take keyboard input, so a program that reads stdin blocks forever and looks hung.

Every one of those is valid JSON with a known key. A linter checks the shape of a file, and a wrong value is a perfectly shaped value.

The cost is not the fix, which takes seconds once you know. The cost is the finding. Nothing points at the line. You notice weeks later, usually on the day a new person clones the repository and their IntelliSense is red in files that compile fine, or the day a VS Code update stops resolving a deprecated name that had been limping along.

So we wrote the check as an extension, and put the same 21 rules on a web page you can paste into. It reads the values. It gives you the line number and what the value should be instead. The free side runs all 21 rules on the file you have open, and inserts any of 45 ready snippets for gtags tasks, c_cpp_properties, formatter save-actions, Dark+ overrides, Tailwind, ASP.NET Core launch profiles and MicroProfile Java. No key, nothing held back.

The part worth paying for is not the answer - it is scale. One file is a coffee break. A repository with forty config files across a monorepo, exported as CSV for a review, with your own team rules checked alongside the built-in 21, is the thing you cannot do by hand for less than the price of an hour of senior developer time.

One last rule, because it is the one that stops being a nuisance and starts being an incident:

{ "githubToken": "ghp_..." }

In a file that lives in the repository. The moment that is pushed the token is public, GitHub revokes leaked tokens automatically, and your gist and repo access stops. Nothing in the editor warns you before the push. That check is free too.