36. Naming Strategies in Vitte

Level: intermediate · Reading time: 9 min · Prerequisite: book/chapters/35-error-message-anatomy.html · Track: supplemental · Maturity: draft · Last review: 2026-05-09

Prerequisites: book/chapters/35-error-message-anatomy.html. See also: book/chapters/35-error-message-anatomy.html, book/chapters/27-grammar.html, book/chapters/31-build-errors.html.

Concrete Problem

Design and convention chapters often become prose-only advice with no proof that the rule changes code quality.

Red Thread (Single Project)

One module is revised from a weak naming or boundary choice into a stronger, more maintainable form.

For what

This chapter helps the reader connect design advice to concrete changes in code review, maintenance, and migration.

What you are going to do

You will inspect one before/after style or architecture decision, then identify the contract it improves.

Coherent example

space demo/design

form BuildConfig {
  project_name: string
  retry_limit: int
}

proc validate_config(cfg: BuildConfig) -> int {
  if cfg.project_name == "" { give 11 }
  if cfg.retry_limit < 0 { give 12 }
  give 0
}

Global explanation

Design pages need code because design rules only matter when they improve a concrete contract. Naming, conventions, compatibility boundaries, and review habits are technical because they change how easily the code can be read and evolved.

Invalid case

form Cfg {
  x: string
  y: int
}

This invalid case is intentionally small. It exists to isolate the contract failure that the chapter is trying to teach.

Common pitfalls

• Giving advice with no concrete code delta.
• Using generic slogans instead of stable review criteria.
• Forgetting to connect naming or convention to future maintenance cost.

Short exercise

Rename one vague field or procedure in the example and explain what ambiguity the new name removes.

Summary in 5 points

1. Design advice must change code, not just prose.
2. Naming and conventions are technical levers.
3. Concrete before/after examples teach better than slogans.
4. Maintainability is visible in small code decisions.
5. The chapter should leave a reusable review rule behind.