Configuring PhpStorm Code Vision and Inline Hints Effectively

1. What Code Vision and inline hints each actually display

Code Vision shows small, clickable hints directly above classes and methods, such as the number of callers in the project or the last known status of related tests. Clicking it opens the list of matches directly, skipping the detour of running Find Usages as a separate command.

Inline hints, by contrast, appear right inside the code itself, usually as grayed out text before an argument or after a method signature, for example the name of a parameter in a function call with several arguments of the same type, or the inferred return type of a method without an explicit declaration.

Both displays can be configured independently of each other and do not need to be active together at all: a developer might, for example, choose Code Vision exclusively and disable inline hints entirely if the plain caller information is enough and parameter information tends to distract.

2. Enabling Code Vision and choosing the right providers

Under Settings, Editor, Inlay Hints, Code Vision, the feature can be enabled overall and then individually configured to show only the providers that actually matter, such as Usages for the caller count or Related Tests for the test status straight from PHPUnit runs.

For a Magento project with many interfaces and plugin classes, Usages is especially valuable, since it makes it obvious at a glance whether a method is still used in production before it gets changed or removed. Related Tests pays off mainly where solid test coverage actually exists.

Less relevant for most Magento teams is the Inheritors provider, which shows the number of subclasses, since inheritance depth in an interface-based project is usually already obvious from the naming anyway.

<!-- Excerpt from editor.xml, exported via Settings Sync -->
<component name="CodeVisionSettings">
  <option name="providers">
    <list>
      <CodeVisionProviderSetting providerId="java.usages" enabled="true" />
      <CodeVisionProviderSetting providerId="testStatusVision" enabled="true" />
      <CodeVisionProviderSetting providerId="inheritors" enabled="false" />
    </list>
  </option>
</component>

3. Parameter hints: when they help and when they distract

In a function call with several consecutive boolean arguments, it is nearly impossible without a hint to tell which value belongs to which parameter. This is exactly where parameter hints show the matching parameter name right before the argument and make the call instantly readable.

In a call with only a single, obvious argument, such as $repository->getById($productId), the same hint is pure redundancy that unnecessarily widens the code. PhpStorm already hides hints automatically for unambiguous cases by default, but this can additionally be fine-tuned manually.

For calls using named arguments, supported by PHP since version 8.0, parameter hints become unnecessary anyway, since the parameter name is already explicit in the code and PhpStorm consistently hides the redundant hint.

// Without a parameter hint: unclear what true/false each mean
$product->setData('status', true, false);

// With a parameter hint (editor display only, not real code):
$product->setData(
    key: 'status', /* $key */
    value: true,   /* $value */
    lockData: false /* $lockData */
);

4. Type hints for PHP 8.4: property promotion and return types

With constructor property promotion, used everywhere in modern PHP 8.4 classes, PhpStorm shows inferred types for readonly properties directly inline whenever no explicit type appears in the code. This particularly helps when quickly skimming unfamiliar classes without constantly jumping to the definition.

For methods without an explicit return type declaration, an inline hint shows PhpStorm's inferred type right after the closing parenthesis of the parameter list. In a project that already enforces PHPStan at level 5 with strict types, such cases are rare, but the remaining exceptions become immediately visible.

final class ProductPriceCalculator
{
    public function __construct(
        private readonly float $basePrice, /* : float */
        private readonly float $taxRate,   /* : float */
    ) {
    }

    public function calculate() /* : float (inferred) */
    {
        return $this->basePrice * (1 + $this->taxRate);
    }
}

5. The performance angle: many hints in large files

In very large, generated, or heavily nested files, a high number of active inlay hint providers can noticeably slow down editor rendering, since every visible line needs additional analysis and labeling. This becomes especially apparent in files spanning several thousand lines.

For such cases it makes sense to reduce hints on a per project or per file basis rather than disabling them globally for all file types. Files under var/generated, for instance, barely benefit from hints since they are never edited by hand anyway, while app/code clearly benefits from the same hints.

A simple practical test helps with the assessment: if scrolling in a particular file becomes noticeably choppy, it is worth a quick look at the hint settings before jumping to blame the machine's hardware or the project's size.

6. Settling on shared team conventions for hints

Since inline hint settings belong to the personal category and run per developer through Settings Sync, without agreement everyone ends up seeing a different view of the same code, which causes confusion especially during pair programming or screen sharing.

A short team consensus, for example Usages and Related Tests on for Code Vision, parameter hints only for boolean and numeric literals, all other hints kept restrained, can be captured as a recommendation in the README or onboarding document and provided as an exported settings file.

7. A concrete configuration example to replicate

Under Settings, Editor, Inlay Hints, Parameter Names, hints can be restricted to appear only for literals like true, false, or numbers, but not for already descriptive variable names, which noticeably reduces distraction without losing the actual benefit.

This fine-tuned configuration can be exported as part of the personal Settings Sync category and passed on as a recommendation to new team members, for example as a short guide with a screenshot in the onboarding document, so nobody just adopts the default without thinking about it.

<!-- Settings, Editor, Inlay Hints, Parameter Names -->
<option name="showForNonLiteralArguments" value="false" />
<option name="showForBooleanLiterals" value="true" />
<option name="showForNumericLiterals" value="true" />
<option name="showForSingleParameterMethods" value="false" />

8. When hints are better switched off entirely

During live demos, pair programming sessions over screen sharing, or when taking screenshots for blog posts and documentation, inline hints often distract, since they offer no value to the audience but add extra visual complexity. A quick toggle via View, Show Inlay Hints helps in these moments.

When working on very old, unclearly typed legacy code, a flood of inferred type hints can unsettle more than it helps, since PhpStorm can often only display rough guesses there. In such areas it is often more honest to switch hints off and research actively instead.

9. Code Vision and inline hints compared to plain navigation

Plain navigation via Find Usages or Go to Declaration delivers the same information as Code Vision, but requires a deliberate extra click and a context switch away from the current code. Code Vision delivers the same signal passively and permanently visible, without any active lookup required.

For occasional, rare questions, classic navigation remains the more resource-friendly choice, since nothing needs to be computed and displayed permanently. For recurring questions, such as caller counts during API changes, the constant visibility of Code Vision is worth the extra rendering cost.

Ultimately the choice between both approaches is not an either or decision: a well configured team uses Code Vision for frequent, recurring questions and deliberately relies on classic, actively triggered navigation for rare edge cases.

10. Summary

11. FAQ: Code Vision and Inline Hints: The Essentials at a Glance