Files
vscode/.github/instructions/coding-guidelines.instructions.md
T
Sandeep Somavarapu 01cb792966 sessions: unify model picker into core via provider getModels API (#319980)
Replace the per-provider model picker actions with a single sessions-core
ModelPicker that wraps the shared workbench ModelPickerActionItem. The core
picker reads the available models from the active session's provider via the
new ISessionsProvider.getModels API, remembers the last used model per provider
per session type, and applies the selection through ISessionsProvider.setModel.

Providers stay authoritative for their own behavior:
- getModels resolves model metadata per provider (local/CLI/agent-host filter
  registered language models; cloud synthesizes metadata from its option group).
- getModelPickerOptions lets each provider decide grouping, featured models and
  whether the Manage Models action is shown, instead of core branching on
  session type.
- onDidChangeModels lets the core picker refresh when models change.

Decouple the core picker from agent-host provider identity: the agent-host
mobile combined config picker now publishes the neutral
ActiveSessionUsesCombinedConfigPickerContext key, which the core picker uses to
gate itself out on phone layouts.

Add architecture guidelines: do not mirror runtime state into context keys,
delegate provider-specific decisions to the provider, and avoid large
mid-method comments.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
2026-06-04 21:25:48 +02:00

3.2 KiB

description, applyTo
description applyTo
VS Code coding guidelines — naming, style, types, strings, and code quality rules. Reference when writing or reviewing code. src/vs/**

Coding Guidelines

Canonical reference: https://github.com/microsoft/vscode/wiki/Coding-Guidelines

Also see the Source Code Organization wiki page.

Indentation

Use tabs, not spaces.

Naming

  • PascalCase for types and enum values
  • camelCase for functions, methods, properties, and local variables
  • Use whole words when possible

Types

  • Do not export types or functions unless shared across multiple components
  • Do not introduce new types or values to the global namespace

Comments

  • Use JSDoc style comments for functions, interfaces, enums, and classes
  • Do not write large comments in the middle of a method or comments that explain a single line. If a line or block needs a paragraph of explanation to be understood, treat that as a signal that the code itself is unclear: extract a well-named function, introduce an explanatory variable, or simplify the logic instead. Keep any remaining inline comment to a brief note.

Strings

  • "double quotes" for user-visible strings that need localization
  • 'single quotes' for everything else
  • All user-visible strings must be externalized via nls.localize() — no string concatenation, use {0} placeholders

UI Labels

  • Title case for command labels, buttons, and menu items (each major word capitalized)
  • Don't capitalize prepositions of four or fewer letters unless first or last word
  • Sentence case for view titles/headings (only first word capitalized), no trailing period

Style

  • Arrow functions over anonymous function expressions
  • Only parenthesize arrow parameters when necessary: x => x + x not (x) => x + x
  • Always surround loop and conditional bodies with curly braces
  • Open curly braces on the same line
  • No surrounding whitespace in parenthesized constructs
  • Prefer export function x(…) {…} over export const x = (…) => {…} at top-level scope (better stack traces)

Code Quality

  • Include Microsoft copyright header in all files
  • Prefer async/await over Promise.then()
  • Localize all user-facing messages
  • Prefer named regex capture groups over numbered ones
  • Do not use any or unknown unless absolutely necessary
  • Register disposables immediately after creation — use DisposableStore, MutableDisposable, or this._register()
  • Declare service dependencies in constructors via DI — never access services through IInstantiationService elsewhere. In particular, do not lazily resolve a service with this.instantiationService.invokeFunction(accessor => accessor.get(ISomeService)); add @ISomeService as a constructor parameter instead. If a constructor cycle prevents direct injection, break the cycle (e.g. pass the dependency into an init()/wiring method from the orchestrator, or relocate the call) rather than reaching through invokeFunction/accessor.get.
  • Use IEditorService to open editors, not IEditorGroupsService.activeGroup.openEditor
  • Avoid bind()/call()/apply() solely for this — prefer arrow functions
  • Avoid events for control flow between components — prefer direct method calls