How to Inspect Code in PyCharm and GoLand

Most developers first encounter JetBrains code inspections as red underlines and yellow warnings inside the editor. That live feedback is the same inspection engine behind Problems, batch runs, and shared profiles, even when the UI says "problem" in places. It's useful, but it isn't the real power move. Instead, learn how to run a deliberate inspection pass across a file, package, module, or whole project before you commit your changes and open a pull request.

That workflow lives in Problems, Project Errors, Code | Inspect Code, scope selection, and inspection profiles. Once you start using this, PyCharm and GoLand stop being fancy editors and become a code quality gate.

By the time a problem reaches CI/CD, you've already paid the context-switch tax:

• You wrote the code.
• You staged it.
• You pushed it.
• You waited for the pipeline.
• You reopened the work.

By contrast, when PyCharm or GoLand finds the issue locally, you can usually fix it while the code is still fresh in your head.

That's the value of leaning on inspections end to end. The IDE isn't only marking mistakes in the current file as you type. It can also run structured inspection passes against broader scopes of code and show you the results in one place, grouped, triaged, and ready to fix.

For a lot of Python and Go developers, that second part is the missing piece.

It also does something more subtle over time: It teaches you patterns.

If you keep paying attention to the same warnings, quick fixes, and inspection results, you start to internalize better habits before the IDE has to remind you.

The Problems Tool Window¶

The Problems tool window is where JetBrains surfaces what its inspections have found.

Open it with:

• Alt+6
• Or View | Tool Windows | Problems

Think of it as three layers of feedback.

Current File¶

This tab is the live editor view. It updates as you type and shows issues in the file currently open in the editor.

It's great for:

• Catching mistakes immediately.
• Navigating issues with F2 and Shift+F2.
• Applying a quick fix with Alt+Enter or ⌥⏎.

Useful, but still narrow.

Project Errors¶

This is the tab that matters for real review workflows.

Project Errors shows inspection results beyond the current file. In practice, this becomes your local review dashboard once you start running manual inspections.

Use it when you want to:

• Review issues across multiple files.
• Inspect a package, directory, module, or full project.
• Find problems introduced during a refactor.
• Clean up a branch before pushing it.
• See the output of an explicit inspection run instead of relying only on editor-time feedback.

This is the point between "the IDE noticed something while I typed" and "I'm actively auditing the codebase."

The practical order is:

1. Catch issues while typing.
2. Run Inspect Code locally.
3. Review results in Project Errors.
4. Let CI and Qodana confirm the same standards later.

If you skip step 2, you're leaving a lot of IDE value unused.

Inspect Code¶

This is the feature that's overlooked.

In both PyCharm and GoLand, go to:

• Code | Inspect Code

This opens a dialog where you choose two things that matter a lot:

• Scope
• Inspection Profile

The editor can only do so much while you're focused on one file. Some inspections are also batch-mode inspections, meaning they're designed to run across a larger scope instead of constantly in the editor.

A manual inspection pass gives you:

• A broader view of problems.
• More consistent results before review.
• A repeatable habit you can run at the end of a feature or refactor.
• A local equivalent of "run the checks before CI embarrasses me."

Choosing the Scope¶

When you run Inspect Code, JetBrains asks what part of the codebase to analyze.

Typical scope choices:

• Current file
• Directory
• Module
• Whole project
• Custom scope
• Uncommitted files

Uncommitted files is especially useful when your project's under version control and you want a fast pre-commit or pre-PR pass.

This is where the feature becomes practical instead of overwhelming.

Use smaller scopes when:

• You're iterating on one package.
• You just refactored one subsystem.
• You want quick feedback without a full project scan.

Use larger scopes when:

• You're preparing a pull request.
• You renamed or moved symbols across many files.
• You want to apply a team profile to the whole codebase.

My default advice:

• During normal coding, inspect the current package or directory.
• Before opening a pull request, inspect the changed module or project.

That keeps the feedback useful without turning every run into a full-repository archaeology dig.

Choosing the Inspection Profile¶

The inspection profile determines which rules run and how severe they are.

This is what turns Inspect Code from a generic scan into a team workflow.

Profiles control:

• Which inspections are enabled.
• Which are disabled.
• Whether something is an error, warning, or weak warning.
• Which scopes use which settings.

In other words, the profile is your local policy engine.

Reading the Inspection Tree¶

This is the part you miss the first time you open the inspection settings panel.

JetBrains doesn't organize inspections only by "the language I'm typing right now." The tree usually covers the full repository surface, though the exact groups depend on the IDE, installed plugins, and project setup.

You might see groups like:

• Python
• Go
• Go modules
• GitHub Actions
• Dockerfile
• Docker-compose
• HCL compatible
• DotEnv
• EditorConfig
• Dev Container
• GitLab CI/CD

That means an inspection profile can describe the real shape of the repo, not just the main application language.

The important habit isn't memorizing this exact list. It's learning to read the tree that exists in your project and tune the profile around that.

For example:

• In a Go repository, you may care about Go, Go modules, GitHub Actions, Dockerfile, and HCL compatible.
• In a Python repository, you may care about Python, GitHub Actions, DotEnv, Docker-compose, and EditorConfig.
• In an infrastructure-heavy repo, you may want HCL, CI, and container inspections enabled even if the application code itself is relatively small.

That's why Inspect Code plus a tuned profile is more powerful than just watching current-file warnings. It lets you analyze the repository you actually ship.

How to Read What the UI Is Telling You¶

The inspections window isn't just a giant checkbox wall. It gives you a few useful signals:

• The Profile dropdown shows which rule set you're editing.
• The search field helps you jump to a technology, inspection family, or keyword fast.
• The filter button narrows the tree to enabled, disabled, modified, or batch-mode inspections.
• A fully checked group is enabled.
• An empty checkbox is disabled.
• A partial checkbox usually means some inspections in that group are enabled and some aren't.

That partial state is often the right answer. Most teams don't want everything enabled. They want a profile that matches the repository they actually maintain.

One more important detail: some groups appear because the IDE or an installed plugin understands that file type. So if you see things like GitHub Actions, Dockerfile, or HCL compatible, that means the IDE can inspect those files too, not just your Python or Go code. If you don't see a group mentioned in this article, trust the tree you have in front of you.

One Workflow, Different Repositories¶

This is the part that matters most: PyCharm and GoLand use the same inspection workflow.

You open Settings | Editor | Inspections. You tune a profile. You choose a scope. You run Code | Inspect Code. You review the findings in Project Errors.

What changes isn't the process. What changes is the repository and the kinds of inspections you want enabled for it.

If the Project Is Mostly Python¶

Start with the Python group first.

A practical baseline is:

• PEP 8 coding style violations
• incorrect type inspections
• unresolved references
• probable bugs and data flow checks
• dead code or unused symbol checks
• naming and spelling checks where they add value

If the repository doesn't use other technologies, disable those groups to reduce noise in Project Errors.

The exact inspection names matter less than the pattern: enable correctness first, then maintainability, then repo-surface checks.

If the Project Is Mostly Go¶

Start with the Go and Go modules groups first, and include Go Template if the repository uses Go templates.

A practical baseline is to review the categories you actually see under those groups.

If the repository doesn't use other technologies, disable those groups so the report stays useful.

In practice, I'd usually prioritize a subset like this first:

If the repository uses Go templates, add the Go Template group and tune the categories you care about there too.

Then I'd layer in style, redundancy, and the repository-level file types that matter to the delivery workflow.

If the Project Is Mixed or Infrastructure Heavy¶

This is where inspection profiles become especially useful.

Many repositories aren't "just Python" or "just Go." They also include:

• .github/workflows/*.yml
• Dockerfile
• compose.yml
• .env.example
• Terraform or OpenTofu files
• dev container definitions

In those repositories, your profile should reflect the repo, not just the primary language.

A good profile might combine:

• language inspections for the main codebase
• CI inspections for workflow files
• container inspections for Docker assets
• HCL inspections for Terraform or OpenTofu
• repository hygiene inspections for .env and EditorConfig

That's the shift in mindset this workflow is meant to create.

Quick Fixes¶

Once Project Errors is full of useful findings, you still need to fix them efficiently.

JetBrains labels some Alt+Enter / ⌥⏎ results as quick fixes and others as intentions, but you reach both from the caret or from a selected problem with the same shortcut.

That's where Alt+Enter or ⌥⏎ comes in.

Use it:

• In the editor
• On a selected item in Problems
• On a selected item in Project Errors

Typical quick-fix outcomes:

• Add missing imports
• Rename a symbol
• Handle an ignored error
• Adjust a type hint
• Reformat or clean up code
• Suppress an inspection intentionally

This matters because Inspect Code without Alt+Enter is just a list of guilt. The quick-fix workflow is what makes the loop practical.

Customizing Inspection Profiles¶

If you want this workflow to scale across a team, profiles matter more than individual shortcuts.

Open:

• Settings | Editor | Inspections

From there you can:

• Duplicate a default profile
• Enable or disable specific inspections
• Change severity
• Tune inspection options
• Copy a profile to the project level

Project-level profiles are the important part for teams. JetBrains stores them in:

.idea/inspectionProfiles/

That means you can commit them to version control and share the same inspection policy with the rest of the team.

Why this is useful:

• Junior developers see the same warnings senior developers expect.
• Pull requests arrive cleaner.
• Fewer problems are deferred to review.
• Local analysis starts matching team standards.

This is one of the best low-friction ways to shift quality checks left.

Build Profiles Around the Repo, Not Just the Language¶

This is the mindset I'd recommend for teams.

Don't build a profile around a slogan like "We are a Go team."

Build it around the repository you actually maintain: a Go repository that may also ship CI workflows, container files, and infrastructure configuration.

Likewise, don't build a Python profile that only cares about Python syntax if the repo also ships the operational surfaces from If the Project Is Mixed or Infrastructure Heavy. The inspection tree already understands much of that surface. Use it.

Once you start thinking this way, the workflow stays simple even when the repository isn't mainly about application code:

1. Tune an inspection profile with the relevant groups enabled.
2. Choose a scope that targets the files or directories you care about.
3. Run Code | Inspect Code.
4. Review the results in Project Errors.

Examples:

• Inspect .github/workflows/ with GitHub Actions inspections enabled.
• Inspect container definitions with Dockerfile and Docker-compose inspections enabled.
• Inspect Terraform or OpenTofu examples with HCL compatible inspections enabled.
• Inspect repository hygiene through DotEnv, EditorConfig, and related groups.

That's the habit worth building: inspect the repository as a system, not just the source file in front of you.

Scope Ideas¶

With that mindset, scope selection becomes much more strategic.

Useful examples:

• Run a custom scope for .github/workflows/ when changing CI.
• Run a directory scope when editing Terraform or OpenTofu.
• Run a selected-files or directory scope on container assets before changing deployment images.
• Run Uncommitted files before a commit when you want a quick local quality gate.

That pairing of scope plus profile is the real workflow upgrade.

A Practical Team Workflow¶

If you want the shortest path from treating the IDE like an editor to treating it like a local quality gate, do this:

During Normal Coding¶

• Watch the inspection widget in the current file.
• Use Alt+Enter or ⌥⏎ instead of ignoring obvious warnings.

Before Opening a Pull Request¶

1. Go to Code | Inspect Code.
2. Choose a useful scope. Good options include the current directory, package, module, changed project area, or even .github/workflows/.
3. Select the team's inspection profile.
4. Run the inspection.
5. Open Problems.
6. Review Project Errors.
7. Fix the high-signal issues first.

Before a Broader Refactor or Cleanup Branch Lands¶

1. Run Inspect Code on the module or project.
2. Group results by severity or inspection type.
3. Apply quick fixes where they're safe.
4. Leave intentional suppressions only where needed.

That's the workflow this article is really about: not "notice a yellow line," but "run a local inspection pass like you mean it."

The biggest missed opportunity in PyCharm and GoLand isn't that people ignore warnings. It's that they never graduate from live editor hints to deliberate project inspection.

If you start using Problems, Project Errors, Code | Inspect Code, scope selection, and shared inspection profiles together, you get a much tighter development loop. The IDE stops being a place where bugs are merely highlighted and becomes a place where they're actively hunted down before review and before CI. That's the habit worth building, and it compounds: if you treat inspections as feedback instead of noise, they teach you better patterns around naming, control flow, typing, error handling, dead code, and repository hygiene, so over time you're not only cleaning up the current branch but strengthening how you write the next one.

References¶