VS Code ist schnell. Dein Setup macht’s langsam. Hier kommt der Stack, der dir wirklich Minuten pro Tag zurückgibt – ohne Extension-Zoo und ohne Dauer-Genervtsein.
Die Wahrheit: Du brauchst keine 40 Extensions. Du brauchst einen Workflow. Extensions sind nur Schraubenzieher. Wenn du aber 30 Schraubenzieher in der Hosentasche trägst, läufst du halt wie ein Pinguin.
Also: Wir bauen ein Setup, das 2026 in echten Projekten funktioniert. Mit zwei Prinzipien:
- Alles, was Format/Lint betrifft: muss eindeutig sein, sonst hast du Chaos (und PR-Diskussionen über Leerzeichen).
- Alles, was “nice” ist (Git-Overlays, Inline-Hinweise, AI): nur, wenn es dich nicht dauerhaft aus dem Flow reißt.
- Pflicht: ESLint + Prettier + EditorConfig (damit Lint/Format nicht gegeneinander kämpfen).
- Review/Team: GitHub Pull Requests & Issues (PRs/Issues direkt in VS Code).
- Text-Qualität: Code Spell Checker (+ Deutsch-Dictionary, wenn du viel Doku/Kommentare schreibst).
- Speed-Booster: GitLens (wenn du viel in fremdem Code wühlst), Error Lens (wenn du Diagnostics sofort sehen willst).
- Pro-Tipp: Nutze Profiles + Settings Sync, damit dein Setup je Projekt “passt” statt überall gleich laut zu sein.
Die goldene Regel: 1 Job = 1 Extension (sonst Krieg)
Die meisten “nervigen” Extensions sind nicht per se schlecht. Sie sind nur doppelt. Zwei Formatter, drei Linters, fünf Git-Dekos – und plötzlich ist jeder Save ein Glücksspiel.
Wenn du nur eine Sache aus diesem Artikel mitnimmst: Entscheide, wer formatiert (Prettier oder was anderes) und wer lintet (ESLint etc.). Und dann: konsequent.
- 2026 ist “Editor-Setup” eigentlich Policy + Sync: Profile pro Kontext, Settings Sync über Geräte.
- AI-Features im Editor werden mehr. Ohne Leitplanken werden sie auch mehr… laut.
- Security ist nicht optional: Extensions sind Supply-Chain. Punkt.
Must-haves: die Extensions, die in echten Projekten fast immer ziehen
1) ESLint: Bugs & Code-Smell früh abfangen
Die ESLint-Extension integriert ESLint in VS Code und nutzt dabei typischerweise die ESLint-Installation aus deinem Workspace (also projektlokal). Das ist gut, weil dein Team dann wirklich dieselben Regeln fährt. (Und nicht “bei mir ist’s grün”.) Wichtig: Installiere ESLint im Projekt, nicht nur irgendwo global. :contentReference[oaicite:0]{index=0}
2) Prettier: Format ist keine Geschmacksfrage (sondern Automation)
Prettier ist ein opinionated Formatter. Heißt: weniger Diskussionen, mehr Konsistenz. Wenn du es nutzt, mach’s klar: Prettier ist der Formatter, ESLint ist der Sheriff. :contentReference[oaicite:1]{index=1}
3) EditorConfig: ein kleines File, weniger “Tabs vs Spaces”-Drama
Die EditorConfig-Extension liest .editorconfig und setzt grundlegende Editor-Settings wie Indent-Größe, Tabs/Spaces, etc. Das ist gerade dann nice, wenn Leute mit unterschiedlichen Editoren arbeiten. :contentReference[oaicite:2]{index=2}
4) GitHub Pull Requests & Issues: Reviews im Flow
Wenn ihr GitHub nutzt: Diese Extension bringt PRs und Issues direkt in VS Code. Reviewen, kommentieren, Kontext sehen – ohne dauernd Browser-Tabs zu jonglieren. :contentReference[oaicite:3]{index=3}
5) Code Spell Checker (+ Deutsch): Doku/Kommentare werden sofort besser
Das Ding ist simpel: Rechtschreibung checken, ohne dich mit False-Positives zu erschlagen. Und ja: Gerade bei README, Changelogs, Tickets, Code-Kommentaren spart das Zeit, weil du weniger “Was meintest du?”-Nachfragen bekommst. Für Deutsch gibt’s ein extra Dictionary-Addon. :contentReference[oaicite:4]{index=4}
Speed-Booster: nice-to-have, aber oft ein echter Zeitgewinn
GitLens: “Wer hat das kaputt gemacht?” in 3 Sekunden
GitLens zeigt dir u.a. Blame/History direkt im Editor (Hover/CodeLens/Annotations). In großen Codebases ist das ein echter Shortcut – du siehst schneller, warum etwas so ist, und wen du fragen musst. Achtung: GitLens hat Community (free) und Pro (Abo) – das beeinflusst, wie weit du kommst. :contentReference[oaicite:5]{index=5}
Error Lens: Diagnostics, die du nicht mehr übersiehst
Error Lens macht VS Codes Diagnostics sichtbarer (z.B. stärkeres Highlighting). Das spart dir “Warum war der Test rot?”-Momente, weil du Warnungen/Fehler früher siehst. Aber: es kann dein Editor-Bild auch “busy” machen. :contentReference[oaicite:6]{index=6}
Remote Development Pack / Dev Containers: Setup stressfrei machen
Wenn du remote devst (SSH, WSL, Container): Das Remote Development Extension Pack (inkl. Dev Containers) kann dir extrem viel Zeit sparen, weil dein Environment reproduzierbarer wird. :contentReference[oaicite:7]{index=7}
- GitLens ist super, wenn du viel “Code-Archeologie” machst. Wenn du fast nur in deinem eigenen Feature-Branch lebst, ist’s eher Deko.
- Error Lens ist geil, wenn du visuell arbeitest. Wenn du schnell genervt bist von “Text im Code”, dreh es runter oder lass es weg.
- Remote/Containers sind ein Multiplikator: einmal richtig, und Onboarding wird plötzlich angenehm.
Die nervigen Kandidaten (nicht “schlecht”, aber oft toxisch fürs Setup)
1) Alles, was doppelt arbeitet
Typischer Stress: zwei Formatter greifen auf Save ein. Oder ESLint fix-on-save + Prettier + “noch ein Formatter”. Ergebnis: Format-Pingpong. Lösung: eine Quelle der Wahrheit.
2) Alles, was deine UI mit Deko zukleistert
Git-Heatmaps, 12 Badges, 8 Inline-Hints – sieht “pro” aus, ist aber oft Noise. Wenn du merkst, du scannst mehr UI als Code: raus damit.
3) AI-Extensions ohne Leitplanken
AI kann dir Zeit sparen (z.B. beim Umbenennen, Fixing, Suchen) – aber nur, wenn du sie steuerst. VS Code beschreibt inzwischen explizit AI-gestützte Actions und Sicherheitsaspekte rund um AI/Agents. Und: Copilot hat Free/Pro-Pläne mit klaren Limits/Preisen. :contentReference[oaicite:8]{index=8}
- “Warum hat der Save wieder alles umformatiert?” – weil zwei Tools sich prügeln.
- “VS Code ist langsam geworden.” – weil 30 Extensions im Hintergrund rummeln und du nie ausmistest.
- “Wir haben aus Versehen eine shady Extension installiert.” – Marketplace ist besser geworden, aber Angriffe & CVEs sind real.
Vergleichstabelle: Zeitgewinn vs Nerv-Faktor
Das ist keine “Top 50”-Liste. Das ist eine “Wenn du das installierst, bekommst du sehr wahrscheinlich echten ROI”-Tabelle.
| Bereich | Extension | Spart Zeit, weil… | Kann nerven, wenn… | Hinweis |
|---|---|---|---|---|
| Qualität | ESLint | Fehler/Regelverstöße früh sichtbar + fixbar | Regeln nicht im Team abgestimmt sind | Am besten projektlokal installieren |
| Format | Prettier | Format automatisch, weniger PR-Nitpicks | Du mehrere Formatter parallel aktiv hast | “Eine Quelle der Wahrheit” |
| Basics | EditorConfig | Einheitliche Indents/Line Endings, cross-editor | Im Projekt kein .editorconfig gepflegt wird | Sehr leichtgewichtig |
| Reviews | GitHub PRs & Issues | Review/Issues ohne Browser-Tab-Wildwuchs | Du nie in VS Code reviewst | GitHub-Login notwendig |
| Text | Code Spell Checker | Weniger Tippfehler in Docs/Kommentaren | Du keine Wörterbücher/Allowlist pflegst | Deutsch-Dictionary verfügbar |
| Git | GitLens | Blame/History im Editor = schneller Kontext | Annotations dich visuell nerven | Community vs Pro (Abo) beachten |
| Feedback | Error Lens | Fehler/Warnungen sofort sichtbar | Inline-Text/Highlights zu “busy” werden | Konfigurierbar, sonst weglassen |
| Environment | Remote Dev / Dev Containers | Reproduzierbares Setup + weniger “works on my machine” | Du es halb einführst (ohne Standards) | Richtig gut fürs Onboarding |
So setzt du’s um: 20 Minuten, dann ist Ruhe
Schritt 1: Profile statt “ein Setup für alles”
VS Code hat Profiles. Nutze das. Beispiel:
- Profil “Frontend”: ESLint, Prettier, GitHub PRs, Spell Checker
- Profil “Backend/Monorepo”: GitLens optional, Remote Dev optional
- Profil “Minimal”: nur Essentials, damit VS Code leicht bleibt
Profiles kannst du über Settings Sync auch auf andere Maschinen mitnehmen. :contentReference[oaicite:9]{index=9}
Schritt 2: Settings Sync aktivieren (aber die Remote-Einschränkung kennen)
Settings Sync synchronisiert Settings, Shortcuts und installierte Extensions zwischen deinen VS Code Instanzen. Aber: VS Code synchronisiert Extensions nicht in/aus Remote-Windows (SSH, Dev Container, WSL). Heißt: du brauchst trotzdem ein bisschen Struktur. :contentReference[oaicite:10]{index=10}
Schritt 3: “Save”-Policy festlegen
// Minimal-Policy, die Ärger verhindert:
1) Prettier ist der Formatter (Format on Save).
2) ESLint macht Linting und optional Fixes (aber nur abgestimmt).
3) Keine zweite Format-Extension aktiv.
4) Wenn ein Projekt abweicht: eigenes VS Code Profile oder Workspace-Settings.Typische Fehler & wie du sie vermeidest
- Fehler: Du installierst Extensions “für alle Projekte”. Fix: Profiles + pro Workspace aktivieren/deaktivieren.
- Fehler: Prettier & ESLint kämpfen. Fix: klare Zuständigkeit: Prettier formatiert, ESLint lintet.
- Fehler: Performance kippt. Fix: regelmäßig ausmisten, schwere Extensions nur im passenden Profil.
- Fehler: Security wird ignoriert. Fix: nur vertrauenswürdige/Verified Publisher, Updates ernst nehmen, suspicious Extensions meiden.
Warum Security hier rein muss: Es gab zuletzt konkrete Warnungen zu Schwachstellen in populären VS Code Extensions (inkl. CVEs) und sogar Fälle von bösartigen Marketplace-Extensions. Das heißt nicht “Panik”. Das heißt: Hygiene. :contentReference[oaicite:11]{index=11}
VS Code dokumentiert außerdem Schutzmaßnahmen im Marketplace (Signaturen, Secret Scanning etc.) und erklärt Extension-Runtime-Security. Gut zu wissen, bevor du “irgendwas” installierst. :contentReference[oaicite:12]{index=12}
FAQ
Welche VS Code Extensions lohnen sich wirklich für jedes Projekt?
Wenn du pragmatisch sein willst: ESLint (wenn JS/TS), Prettier, EditorConfig und ein Spell Checker. Dazu GitHub PRs, wenn ihr auf GitHub arbeitet. Alles andere: abhängig vom Workflow.
Welche VS Code Erweiterungen sind “nervig”?
Die nervigsten sind meist doppelte: zwei Formatter, drei Tools, die auf Save eingreifen, oder Extensions, die deine UI mit Badges/Overlays zukleistern. Nicht “schlecht”, nur: zu viel.
Wie konfiguriere ich ESLint und Prettier in VS Code ohne Konflikte?
Einfaches Modell: Prettier macht Format on Save, ESLint macht Linting (und nur Fixes, die ihr wirklich wollt). Wichtig ist, dass ESLint aus dem Projekt kommt (workspace dependency), damit alle dieselbe Version nutzen. :contentReference[oaicite:13]{index=13}
Lohnt sich GitLens 2026 noch?
Wenn du viel in fremdem Code debugst: ja, weil Kontext/History extrem schnell da ist. Wenn dich Blame-Overlays nerven: nutz es gezielt oder schalte Deko ab. Community ist free, Pro ist Abo. :contentReference[oaicite:14]{index=14}
Wie nutze ich VS Code Profiles und Settings Sync sinnvoll?
Baue 2–3 Profiles (Minimal, Projekt/Stack, Remote) und sync sie. Dann installierst du schwere Extensions nicht überall. Beachte: Extensions werden nicht in/aus Remote-Windows synchronisiert (SSH/Containers/WSL). :contentReference[oaicite:15]{index=15}
Wie sicher sind VS Code Extensions?
Grundsätzlich: besser als früher (Signaturen, Marketplace-Checks), aber kein “alles safe”. Es gab reale Fälle mit CVEs und bösartigen Extensions. Praktisch heißt das: Verified Publisher bevorzugen, Updates ernst nehmen, Extension-Liste regelmäßig reviewen. :contentReference[oaicite:16]{index=16}
Welche Extensions helfen bei Remote/Dev Containers am meisten?
Remote Development Extension Pack + Dev Containers sind die naheliegenden Kandidaten, wenn du per SSH, WSL oder Container entwickelst. Der Gewinn ist weniger “Features”, mehr: reproduzierbares Environment. :contentReference[oaicite:17]{index=17}
Fazit: dein Setup soll leise sein
Ein gutes VS Code Setup merkst du daran, dass du nicht ständig daran denkst. Du schreibst Code, du fixst Bugs, du lieferst. Der Editor hilft – und hält die Klappe.
Nächster Schritt: Bau dir drei Profiles (Minimal, Projekt, Remote). Installier die Must-haves. Dann: eine Woche arbeiten. Danach gnadenlos ausmisten, was dich nervt.