Code style and naming

Platform spec node

Code style and naming

Back to Program structure ◎ Open in platform map

Spec standingProposed

Owner

Piotr Mikstacki pmikstacki@cybernomad.it

Submitter

Piotr Mikstacki pmikstacki@cybernomad.it

Current document

ADRs

No architecture decision records under adr/ for this feature yet. Standard features must publish at least one ADR or keep a ## Decisions summary on the hub.

Articles

• Code style and naming Language-level naming and style conventions that affect readability and tooling consistency. article Proposed
• extend type Type extension syntax replacing impl blocks; public members only, full type scope access. article Standard Reviewed Wed May 20
• Modules and visibility File layout, `public`/`internal` boundaries, and how packages compose. The driver and package manager use the same module graph the typechecker sees. article Standard Reviewed Thu May 21
• Name resolution Scopes, imports, and shadowing tie syntax to symbols. Diagnostics for unresolved names must cite these rules verbatim. article Standard Reviewed Thu May 21

History

0 revisions (git unavailable at build; counts may be empty)

Open full history on GitHub

No commits recorded for this path.

Completeness

OKarea · 2 SpecSection(s) · 0 H2 heading(s)

Section id	Required	Found
scope	yes	yes
features	yes	yes

Full tree: run pnpm verify:platform-spec-layout (writes src/generated/platform-spec-layout-report.json).

Related spec docs

• Area
  Program structure

  Parent area

• Area
  CLI

  Formatter and linting workflows consume style assumptions

Normative specification

This chapter defines naming and style constraints intended to be enforceable by formatter and lint tooling once promoted to Standard (normative) standing.

Platform view

• Naming conventions shall be stable enough for generated docs and symbols.
• Formatting conventions shall align with beskid_analysis formatter output for code examples.
• Diagnostic messaging should use canonical term names from this chapter.