Code Vision und Inline Hints in PhpStorm sinnvoll konfigurieren

1. Was Code Vision und Inline Hints jeweils genau anzeigen

Code Vision blendet kleine, klickbare Hinweise direkt oberhalb von Klassen und Methoden ein, etwa die Anzahl der Aufrufer im Projekt oder den zuletzt bekannten Status zugehoeriger Tests. Ein Klick darauf oeffnet direkt die Liste der Fundstellen, ohne den Umweg ueber Find Usages als separaten Befehl.

Inline Hints dagegen erscheinen mitten im Code selbst, meist als grau hinterlegter Text vor einem Argument oder nach einer Methodensignatur, etwa der Name eines Parameters bei einem Funktionsaufruf mit mehreren gleichartigen Argumenten oder der inferierte Rueckgabetyp einer Methode ohne explizite Deklaration.

Beide Anzeigen lassen sich unabhaengig voneinander konfigurieren und muessen keineswegs gemeinsam aktiv sein: Ein Entwickler kann sich beispielsweise ausschliesslich fuer Code Vision entscheiden und Inline Hints komplett deaktivieren, wenn ihm die reine Aufrufer-Information genuegt und Parameterinformationen eher stoeren.

2. Code Vision aktivieren und die richtigen Provider auswaehlen

Unter Settings, Editor, Inlay Hints, Code Vision laesst sich die Funktion insgesamt aktivieren und dann einzeln festlegen, welche Provider tatsaechlich angezeigt werden sollen, etwa Usages fuer die Aufrufer-Anzahl oder Related Tests fuer den Test-Status direkt aus PHPUnit-Runs.

Fuer ein Magento-Projekt mit vielen Interfaces und Plugin-Klassen ist Usages besonders wertvoll, da sich damit auf einen Blick erkennen laesst, ob eine Methode noch produktiv genutzt wird, bevor sie geaendert oder entfernt wird. Related Tests lohnt sich vor allem dort, wo tatsaechlich eine belastbare Testabdeckung existiert.

Weniger relevant fuer die meisten Magento-Teams ist dagegen der Inheritors-Provider, der die Anzahl der Unterklassen anzeigt, da Vererbungstiefen in einem Interface-basierten Projekt meist ohnehin schon aus der Namensgebung ersichtlich sind.

<!-- Auszug aus editor.xml, exportiert ueber 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: wann sie helfen und wann sie ablenken

Bei einem Funktionsaufruf mit mehreren aufeinanderfolgenden boolschen Argumenten ist es ohne Hint fast unmoeglich zu erkennen, welcher Wert fuer welchen Parameter gilt. Genau hier zeigen Parameter-Hints direkt vor dem Argument den zugehoerigen Parameternamen an und machen den Aufruf sofort lesbar.

Bei einem Aufruf mit nur einem einzigen, offensichtlichen Argument, etwa $repository->getById($productId), ist derselbe Hint dagegen reine Redundanz, die den Code unnoetig verbreitert. PhpStorm blendet Hints fuer eindeutige Faelle standardmaessig bereits automatisch aus, laesst sich aber zusaetzlich manuell feinjustieren.

Bei Aufrufen mit benannten Argumenten, wie sie PHP seit Version 8.0 unterstuetzt, werden Parameter-Hints ohnehin automatisch ueberfluessig, da der Parametername bereits explizit im Code steht und PhpStorm den redundanten Hinweis konsequent ausblendet.

// Ohne Parameter-Hint: unklar, was true/false jeweils bedeutet
$product->setData('status', true, false);

// Mit Parameter-Hint (Editor-Anzeige, kein echter Code):
$product->setData(
    key: 'status', /* $key */
    value: true,   /* $value */
    lockData: false /* $lockData */
);

4. Typ-Hints fuer PHP 8.4: Property Promotion und Rueckgabetypen

Bei Constructor Property Promotion, wie sie in modernen PHP-8.4-Klassen ueberall verwendet wird, zeigt PhpStorm inferierte Typen fuer readonly-Properties direkt inline an, sofern kein expliziter Typ im Code steht. Das hilft besonders beim schnellen Ueberfliegen fremder Klassen ohne staendiges Springen zur Definition.

Fuer Methoden ohne explizite Rueckgabetyp-Deklaration zeigt ein Inline Hint den von PhpStorm inferierten Typ direkt nach der schliessenden Klammer der Parameterliste. In einem Projekt, das ohnehin PHPStan auf Level 5 mit strikten Typen fordert, sind solche Faelle selten, machen die verbleibenden Ausnahmen aber sofort sichtbar.

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

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

5. Der Performance-Aspekt: viele Hints in grossen Dateien

In sehr grossen, generierten oder stark verschachtelten Dateien kann eine hohe Anzahl aktiver Inlay-Hint-Provider das Rendering des Editors spuerbar verlangsamen, da jede sichtbare Zeile zusaetzlich analysiert und beschriftet werden muss. Das faellt besonders bei Dateien mit mehreren tausend Zeilen auf.

Fuer solche Faelle bietet sich an, Hints projekt- oder dateispezifisch zu reduzieren, statt sie global fuer alle Dateitypen zu deaktivieren. Var/generated-Dateien etwa profitieren kaum von Hints, da sie ohnehin nicht von Hand bearbeitet werden, waehrend app/code von denselben Hints deutlich profitiert.

Ein einfacher Praxistest hilft bei der Einschaetzung: Wird das Scrollen in einer bestimmten Datei spuerbar ruckelig, lohnt sich ein kurzer Blick in die Hint-Einstellungen, bevor voreilig die Rechnerhardware oder die Projektgroesse als Ursache vermutet werden.

6. Gemeinsame Team-Konventionen fuer Hints festlegen

Da Inline-Hint-Einstellungen zur persoenlichen Kategorie gehoeren und ueber Settings Sync individuell pro Entwickler laufen, sieht ohne Absprache jeder eine andere Ansicht desselben Codes, was gerade bei Pair Programming oder Screen-Sharing fuer Verwirrung sorgt.

Ein kurzer Team-Konsens, etwa Usages und Related Tests fuer Code Vision an, Parameter-Hints nur fuer boolsche und numerische Literale an, alle anderen Hints eher zurueckhaltend, laesst sich als Empfehlung im README oder Onboarding-Dokument festhalten und als exportierte Settings-Datei bereitstellen.

7. Ein konkretes Konfigurationsbeispiel zum Nachbauen

Unter Settings, Editor, Inlay Hints, Parameter Names laesst sich festlegen, dass Hints nur bei Literalen wie true, false oder Zahlen erscheinen, nicht aber bei bereits sprechenden Variablennamen, was die Ablenkung deutlich reduziert, ohne den eigentlichen Nutzen zu verlieren.

Diese Feinkonfiguration laesst sich als Teil der persoenlichen Settings Sync Kategorie exportieren und als Empfehlung an neue Teammitglieder weitergeben, etwa als kurze Anleitung mit Screenshot im Onboarding-Dokument, damit niemand die Standardeinstellung unreflektiert uebernimmt.

<!-- 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. Wann Hints besser komplett abgeschaltet werden

Bei Live-Demos, Pair-Programming-Sessions ueber Screen-Sharing oder Screenshots fuer Blogartikel und Dokumentation lenken Inline Hints oft ab, da sie fuer das Publikum keinen Mehrwert bieten, aber zusaetzliche visuelle Komplexitaet erzeugen. Ein schneller Toggle ueber View, Show Inlay Hints hilft in solchen Momenten.

Auch beim Arbeiten an sehr altem, unklar typisiertem Legacy-Code kann eine Flut inferierter Typ-Hints eher verunsichern als helfen, da PhpStorm dort haeufiger nur grobe Vermutungen anzeigen kann. In solchen Bereichen ist es oft ehrlicher, die Hints abzuschalten und stattdessen aktiv zu recherchieren.

9. Code Vision und Inline Hints im Vergleich zu reiner Navigation

Reine Navigation ueber Find Usages oder Go to Declaration liefert dieselbe Information wie Code Vision, erfordert aber einen bewussten zusaetzlichen Klick und einen Kontextwechsel weg vom aktuellen Code. Code Vision liefert dasselbe Signal passiv und dauerhaft sichtbar, ohne dass aktiv danach gesucht werden muss.

Fuer punktuelle, seltene Fragen bleibt klassische Navigation die ressourcenschonendere Wahl, da nichts dauerhaft berechnet und angezeigt werden muss. Fuer wiederkehrende Fragen wie Aufrufer-Anzahl bei API-Aenderungen lohnt sich dagegen die staendige Sichtbarkeit von Code Vision trotz des zusaetzlichen Rendering-Aufwands.

Letztlich ist die Wahl zwischen beiden Ansaetzen keine Entweder-oder-Entscheidung: Ein gut konfiguriertes Team nutzt Code Vision fuer haeufige, wiederkehrende Fragen und verlaesst sich fuer seltene Spezialfaelle bewusst auf die klassische, bewusst aktiv ausgeloeste Navigation.

10. Zusammenfassung

11. FAQ: Code Vision und Inline Hints: Das Wichtigste auf einen Blick