Asher Wolfstein Meta Code Style v0.0.4

MUST and MUST NOT identify requirements.
SHOULD and SHOULD NOT identify strong defaults that may be departed from when grammar, correctness, or clarity requires it.
MAY identifies an optional form.

[META-NORM-02] Every normative rule MUST have a stable identifier. An identifier MUST define its requirement in exactly 1 location; other rules SHOULD refer to that identifier instead of restating it.

[META-NORM-03] Unidentified prose, diagrams, and worked examples are nonnormative. If an example disagrees with an identified rule, the identified rule controls.

[META-NORM-04] Grammar, type correctness, runtime behavior, evaluation order, name resolution, source compatibility, and required tooling MUST take priority over formatting. Formatting MUST NOT alter any of them.

[META-NORM-05] A construct-specific rule explicitly identified as an exception MUST override a general rule. Otherwise, the general rule applies.

[META-NORM-06] Existing source SHOULD be consulted only when a profile remains incomplete. A repeated local pattern SHOULD be preferred to a one-off example, but existing source MUST NOT override an explicit rule.

[META-NORM-07] A language specification, reference implementation, or target compiler MUST be the authority for syntax and semantics. Community conventions and formatter behavior SHOULD inform the profile but MUST NOT be mistaken for intrinsic rules of the language.

1.2. Purpose

This document defines a method for producing a coherent style guide for a programming language. It is not a direct formatting standard for source code. A language-specific guide, called a language profile, instantiates its concepts using the grammar, semantics, tooling, and conventions of a particular language and version.

The given methodology uses whitespace, indentation, delimiter placement, and vertical alignment especially to expose source structure and evaluation order. Compact syntax is preferred for language-specific statements and expressions, such as variable assignment. Expanded syntax is preferred when it reveals relationships among operands, declarations, list items, branches, and other structural units.

[META-SCOPE-01] A language profile based on this guide MUST identify:

its language, dialect, and supported versions;
the source and file kinds to which it applies;
vendored, generated, embedded, or tool-controlled source that it excludes; and
any formatter, compiler, parser, or linter that controls part of its output.

[META-SCOPE-02] This meta-guide MUST NOT be treated as part of a language profile itself. A language profile MUST first map a meta-rule to syntax supported by its target language in order for a rule to apply.

[META-SCOPE-03] Examples in either this guide or a derived profile MUST NOT be treated as rules for concerns outside their stated scope.

1.3. Priorities [META-PRIORITY]

[META-PRIORITY-01] A language profile SHOULD prioritize, in order:

Correctness and supported syntax.
Visible structure and evaluation order.
Clear control flow and ownership.
Consistency within the surrounding logical unit.
Compatibility with required tools.
Compactness.

[META-PRIORITY-02] Formatting SHOULD make related tokens appear related. It MUST NOT imply a scope, dependency, grouping, or execution order that the program does not have.

[META-PRIORITY-03] A profile SHOULD prefer a small set of composable general rules as opposed to repeated construct-specific prescriptions. A special rule SHOULD exist only when the target language or clarification requires it.

1.4. Core Rules And Portable Defaults [META-PORT]

Rules about correctness, rule ownership, explicit exceptions, and validation are core requirements for every profile.

[META-PORT-01] Whitespace counts, line length, delimiter placement, operator position, and break thresholds are portable defaults that a profile MAY adapt.

[META-PORT-02] A profile MUST adopt each applicable core requirement. It MUST replace an inapplicable portable default with an explicit language-specific decision rather than remaining incomplete or ambiguous.

[META-PORT-03] An adaptation MUST state the language fact that requires it, the replacement behavior, and the constructs affected. An adaptation MUST NOT be broader than that reason requires.

2. Source And Layout Model

2.1. Source Units [META-TOKEN]

This guide distinguishes grammatical structure from the units used for visual layout.

A lexical token is a token as recognized by the target language.
A style token is a source unit treated as 1 item for spacing or alignment.
A protected source unit is text whose internal characters cannot be reformatted independently.
A composite operand contains internal structure but behaves as 1 operand in its enclosing context.
A construct is a language-specific grammatical unit such as an expression, declaration, list, block, or directive.

[META-TOKEN-01] A profile MUST inventory its style tokens and protected source units. The inventory MUST include, when applicable, identifiers, keywords, literals, comments, operators, delimiters, separators, annotations, directives, interpolation forms, and empty delimiter pairs.

[META-TOKEN-02] A multi-character token or grammar-required adjacency MUST remain indivisible. Characters MUST NOT be separated when doing so would change tokenization, parsing, meaning, or tool interpretation.

[META-TOKEN-03] A string, comment, regular expression, heredoc-like form, embedded language, generated fragment, or other protected source unit MUST NOT be internally reformatted unless a dedicated rule governs that unit’s own language either within the profile or within that language’s own profile.

[META-TOKEN-04] A token with context-dependent roles MUST be classified by grammatical use. The same spelling may require different layouts depending on whether it is a unary operator, binary operator, separator, annotation marker, type constructor, or delimiter.

[META-TOKEN-05] A composite operand MUST establish and retain its own local layout context. Operators within it MUST be aligned and counted according to that local context, but MUST NOT participate in alignment or operator counting in any containing context.

2.2. Layout Terms [META-LAYOUT]

A structural base is the column at which a statement, declaration, expression, or block begins.
An operator base is the column occupied by the controlling operator or relation in a multiline construct.
An operand column is the column at which operands of that controlling relation begin.
An alignment base is the first column shared by equivalent items.
A local context is a bounded region whose internal alignment is independent of its container.
An alignment group is a contiguous set of related items whose comparable tokens shall align with one another.
A continuation is a physical line that continues a grammatical unit begun earlier.

[META-LAYOUT-01] Every multiline construct MUST have an identifiable structural base. Every nested multiline construct MUST derive its base from the grammatical position it occupies rather than from an unrelated fixed continuation width.

[META-LAYOUT-02] Structural indentation MUST identify scope or containment. Alignment spaces MUST identify relationships within that structure and MUST NOT create the appearance of another scope.

[META-LAYOUT-03] A local context MUST own its internal breaks, indentation, and alignment. Tokens inside it MUST NOT be pulled outward merely to align with tokens in a containing or neighboring context.

3. Language Profile Foundation [META-PROFILE]

3.1. Language Facts

[META-PROFILE-01] Before deriving layout rules, a profile MUST document or cross-reference the language and tooling acts that constrain those rules. For each concern below, it MUST identify the applicable mechanism and authority or explicitly mark the concern inapplicable.

Concern	Required Fact Or Reference
Language target	Language, dialect, edition, and version range
Grammar authority	Specification, parser, compiler, or reference implementation
Whitespace	Whether spaces, tabs, indentation, or newlines are significant
Statement boundaries	Explicit terminators, significant newlines, or automatic insertion rules
Continuation	Where line breaks are legal and whether an escape is required
Token adjacency	Tokens or token pairs that must remain joined
Operators	Arity, precedence, associativity, fixity, and evaluation guarantees
Delimiters	Legal pairs, ownership, empty forms, and nesting behavior
Comments	Line, block, documentation, directive, and trailing forms
Literals	Multiline, interpolated, raw, regular-expression, and embedded forms
Declarations	Signatures, modifiers, annotations, types, defaults, and bodies
Control flow	Branches, loops, pattern matching, handlers, and transfers
Metaprogramming	Macros, preprocessors, generated regions, or token trees
Tooling	Required formatter, linter, parser, compiler, and editor constraints

[META-PROFILE-01-TABLE-01]

[META-PROFILE-02] A profile MUST distinguish invalid syntax, syntax that is valid but unsupported by the target version, syntax that is deprecated, and syntax that is merely discouraged by style.

[META-PROFILE-03] If a required formatter owns the complete representation, the profile SHOULD delegate overlapping physical-layout choices to that formatter. Project rules SHOULD then address configuration, naming, organization, and concerns the formatter does not own.

3.2. Operators And Relations [META-GRAMMAR]

[META-GRAMMAR-01] A profile for a language with infix, prefix, postfix, or mixfix operators MUST maintain an operator table containing:

Field	Meaning
Spelling	The complete indivisible token or token sequence
Role	Unary, binary, n-ary, separator, binder, or another grammatical role
Fixity	Prefix, infix, postfix, circumfix, or mixfix
Precedence	Relative binding strength in the target grammar
Associativity	Left, right, none, or grammar-specific
Evaluation	Any order, short-circuiting, laziness, sequencing, or undefined behavior
Break legality	Whether the token may lead or trail a continued line
Context exceptions	Uses whose role or precedence differs

[META-GRAMMAR-01-TABLE-01]

[META-GRAMMAR-02] The profile’s visual hierarchy MUST be derived from the parsed structure, not from token spelling alone. Parentheses, grouping forms, implicit application, pattern syntax, and context-dependent precedence MUST be respected.

[META-GRAMMAR-03] When the language does not use precedence-based expressions, the profile MUST identify the equivalent structural relation, such as syntax-tree nesting, list nesting, dataflow order, or explicit block ownership.

3.3. Delimiter Inventory [META-DELIM]

[META-DELIM-01] A profile MUST maintain a delimiter matrix for every applicable context:

call arguments;
declaration parameters;
grouped expression;
data literal;
index or slice;
annotation or attribute;
block or body; and
any other language-specific form.

And for every form:

compact form;
multiline opener;
multiline closer;
empty form;
trailing separator where applicable; and
any other language-specific placement.

[META-DELIM-02] Each nonempty delimiter pair SHOULD establish a local context. A profile MUST document any delimiter whose contents instead share the containing context.

[META-DELIM-03] Opening and closing delimiter placement MUST reveal ownership. A closer MUST NOT be positioned so that it appears to close a neighboring or outer construct.

[META-DELIM-04] Consecutive delimiters SHOULD remain visually adjacent when their contexts begin or end together. They MUST separate when adjacency would hide distinct ownership or violate the grammar.

3.4. Derivation Workflow

[META-PROFILE-04] A language profile SHOULD be developed in this order:

Fix the language, dialect, version range, source scope, and required tools.
Record language facts, protected units, operator relations, delimiters, and legal break positions.
Adopt each portable default or document its narrow language-specific adaptation under META-PORT-03.
Populate the construct inventory and give every distinct behavior 1 owning rule.
Add minimal examples, exception records, formatter configuration, and validation fixtures.
Run source, rule, compatibility, and idempotence checks before publishing the profile.

4. Portable Layout Architecture

4.1. Whitespace And Physical Lines [META-SPACE]

[META-SPACE-01] Adjacent style tokens SHOULD be separated by visible whitespace when the grammar permits and adjacency (lacking whitespace) does not communicate a language-defined relationship. Required adjacency and protected units MUST override this default.

[META-SPACE-02] A profile SHOULD use 2 spaces for each structural indentation level. It MAY choose another unit when the grammar, an enforced formatter, a fixed-column representation, or a binding project constraint requires one.

[META-SPACE-03] Tabs SHOULD NOT be used for indentation or alignment. A profile for a language or representation in which tabs are semantic or mandatory MUST define their exact role and MUST NOT mix that role with visual padding.

[META-SPACE-04] Trailing whitespace MUST NOT be present unless it is semantically significant. When it is significant, the profile MUST define a visible validation strategy that protects it from accidental removal.

[META-SPACE-05] A profile SHOULD use 120 columns as its default soft line limit. It MAY choose another limit for ecosystem, display, or tool compatibility. An indivisible source unit MAY exceed the limit when breaking it would be illegal or less clear.

[META-SPACE-06] Additional spaces MAY align comparable tokens inside 1 alignment group. Alignment MUST NOT cross an unrelated statement, declaration, container, branch, handler, scope, or blank-line boundary.

[META-SPACE-07] Blank lines MAY separate conceptual or alignment groups. A blank line MUST NOT imply a grammatical grouping, scope, or execution boundary that the language does not provide.

[META-SPACE-08] A line break MUST NOT be introduced where the language treats a newline as termination, changes automatic terminator insertion, alters indentation semantics, changes a preprocessor directive, or otherwise affects parsing.

4.2. Hierarchy And Alignment [META-ALIGN]

[META-ALIGN-01] Multiline layout MUST mirror the construct’s syntax tree or equivalent structural hierarchy. An outer controlling relation MUST appear no farther right than a relation nested inside one of its operands.

[META-ALIGN-02] When leading-operator continuation is legal, a construct’s controlling operator token—or the aligned tokens of a single mixfix operator—SHOULD occupy the construct’s operator base. Its peer operands SHOULD begin in a common operand column, normally 1 space after the widest controlling token. When the construct is nested as an operand, its operator base SHOULD begin at the containing context’s operand column.

[META-ALIGN-03] Equivalent operators or separators at the same grammatical level SHOULD align vertically. Operators MUST NOT align when doing so would imply an associativity or grouping different from the parsed program.

[META-ALIGN-04] When leading operators are illegal, unsafe, or strongly misleading in the target language, the profile MUST define a trailing-operator or enclosing-delimiter alternative that preserves the same visible hierarchy.

[META-ALIGN-05] Formatting MUST preserve associativity, short-circuit boundaries, sequence points, lazy evaluation, exception boundaries, and other evaluation constraints. Explicit grouping SHOULD be added when layout alone cannot make the intended grouping clear, and the grouping does not alter behavior.

[META-ALIGN-06] When hierarchy-based alignment would exceed the line limit or create excessive space, a clearer accommodating indentation SHOULD replace it. The fallback SHOULD be the smallest regular indentation that preserves ownership.

4.3. Break Decisions [META-BREAK]

[META-BREAK-01] A profile MUST define deterministic conditions under which each expression, list, declaration, header, and body remains compact or becomes multiline.

[META-BREAK-02] The following portable defaults SHOULD be used, but MUST NOT violate the target grammar:

an assignment used as a complete statement MUST become multiline;
a context with no assignment and no more than 1 structural operator MAY remain compact;
a context with 2 or more structural operators MUST become multiline;
a list with 1 or 2 simple items MAY remain compact;
a list with 3 or more items MUST become multiline; and
when a breakable construct exceeds the line limit, the innermost local context that can legally reflow the overflowing item MUST become multiline; the break MUST propagate outward only as required by META-BREAK-04.

[META-BREAK-03] Operator counts and complexity thresholds MUST be calculated separately for each local context. Content inside a nested context or composite operand MUST NOT cause an unrelated outer context to cross its threshold.

[META-BREAK-04] When a child construct becomes multiline, the profile MUST define whether and how that break propagates to its parent. Break propagation MUST preserve delimiter ownership and MUST NOT flatten the child’s local alignment into the parent.

[META-BREAK-05] Once a context is multiline, equivalent continuation tokens SHOULD use a consistent leading or trailing position as defined by the language profile.

[META-BREAK-06] A protected source unit MUST NOT be broken merely to satisfy a stylistic threshold. The containing construct SHOULD use an accommodating layout instead.

[META-BREAK-07] Formatting decisions SHOULD be stable: adding or removing an unrelated line SHOULD NOT reflow distant alignment groups, and formatting already conforming source MUST be idempotent.

4.4. Lists And Repeated Items [META-LIST]

[META-LIST-01] A profile MUST distinguish grammatical list kinds, including arguments, parameters, generic or type arguments, data entries, inheritance lists, import lists, pattern alternatives, and language-specific lists. Rules for 1 list kind MUST NOT be assumed to govern another.

[META-LIST-02] When legal, a multiline expression-item list SHOULD keep its opening delimiter with the first item, align each later item with the first item’s alignment base, and keep its closing delimiter with the final item. A profile MUST define exceptions for signatures, headers, or conventional hanging-delimiter forms.

[META-LIST-03] A multiline declaration parameter list SHOULD place the opener at the end of the declaration head, place each parameter on its own line, and place the closer at the declaration’s structural base when a body follows. A language profile MUST adapt this default when its grammar or formatter requires another form.

[META-LIST-04] The profile MUST decide trailing-separator behavior independently for each list kind. The decision MUST account for grammar support, diff stability, delimiter placement, variadic markers, and formatter behavior.

[META-LIST-05] The complexity of each top-level item MUST be assessed within that item. A complex item MAY expand the containing list, but operators inside a deeper nested context MUST NOT be counted as siblings of the item.

[META-LIST-06] Prefix markers, default separators, key/value separators, and comparable suffixes MAY form local alignment columns. A long item MAY begin a new group so that it does not impose excessive padding on shorter items.

5. Construct Profile

5.1. Construct Inventory [META-CONSTRUCT]

[META-CONSTRUCT-01] A language profile MUST classify every in-scope construct that has distinct layout behavior. Each entry MUST record:

Field	Required Content
Construct	The language’s name for the grammatical form
Grammar node	The specification or parser category that owns it
Outer role	Atomic unit, operand, declaration, statement, body, or directive
Internal contexts	Expressions, lists, signatures, captures, patterns, types, or bodies
Compact condition	When the complete form may remain on 1 line
Break triggers	Count, complexity, comments, line limit, or mandatory grammar
Multiline bases	Structural, operator, operand, and item alignment columns
Delimiters	Opener, closer, empty form, and ownership
Separators	Position, alignment, and trailing behavior
Ordering	Modifier, clause, branch, member, or evaluation order constraints
Exceptions	Explicit references to overridden general rules
Validation	Parser, compiler, linter, formatter, or fixture coverage

[META-CONSTRUCT-02] The inventory MUST cover each applicable family below and mark an inapplicable family explicitly:

names, qualification, member access, optional access, and chaining;
indexing, slicing, dereferencing, and postfix operations;
calls, construction, argument lists, and named arguments;
functions, methods, parameters, return declarations, and defaults;
closures, lambdas, callable references, captures, and generators;
literals, collections, mappings, records, tuples, and destructuring;
unary, binary, n-ary, conditional, pipeline, and assignment expressions;
annotations, attributes, decorators, modifiers, and visibility;
types, generic constraints, unions, intersections, and nullability;
classes, interfaces, traits, protocols, enums, modules, and namespaces;
conditionals, loops, switches, matches, handlers, and control transfers;
imports, includes, directives, pragmas, macros, and preprocessing; and
comments, documentation, embedded languages, and generated regions.

5.2. Reusable Construct Principles

5.2.1. (Fluent-)Chains [META-CHAIN]

[META-CHAIN-01] A member, selector, path, or fluent-chain step SHOULD remain part of its subject’s composite operand. When a repeated chain becomes multiline, equivalent chain operators SHOULD align within that chain and MUST NOT align across a different chain or nested call.

5.2.2. Indices, Postfixes, And Suffices [META-SUFFIX]

[META-SUFFIX-01] An index, slice, dereference, generic application, call suffix, or other postfix form SHOULD remain visually attached to the subject it modifies. Repeated suffixes SHOULD align by their opening token when doing so exposes their shared subject.

5.2.3. Signatures [META-CALL]

[META-CALL-01] Calls and declarations MUST have separate list policies. Arguments are expressions supplied by a caller; parameters are declarations owned by a signature. Similar delimiters MUST NOT erase that distinction.

5.2.4. Declarations And Their Modifiers [META-DECL]

[META-DECL-01] A declaration’s annotations, modifiers, type components, prefix markers, name, default, constraints, and body MUST remain parts of that declaration. A profile MUST define their legal and canonical relative order without implying that every combination is valid.

5.2.5. Assignment Operations [META-ASSIGN]

[META-ASSIGN-01] A profile MUST distinguish assignment operators from visually similar declaration separators, key/value separators, named-argument separators, pattern binders, and arm separators. Each grammatical role MUST own its own break and alignment rule.

5.2.6. Prefix And Postfix Operators [META-PREFIX]

[META-PREFIX-01] Prefix and postfix operators MUST remain attached to their grammatical operands. A repeated prefix marker MAY receive an alignment column when that column exposes a real parallel relationship, such as negated conditions or reference parameters.

5.2.7. Literals [META-LITERAL]

[META-LITERAL-01] A data literal MUST establish its own item context. Key/value alignment MAY occur within a related group, but source order MUST NOT be changed when order affects evaluation, iteration, serialization, matching, or user-visible output.

5.2.8. Callables [META-CALLABLE]

[META-CALLABLE-01] A closure, lambda, callable reference, anonymous type, or comparable expression with an internal signature or body MUST remain 1 composite operand of its container. Its parameters, captures, return declaration, body expression, and block body MUST retain their own local contexts.

5.2.9. Typing [META-TYPE]

[META-TYPE-01] A profile with type syntax MUST distinguish atomic types from composite type relations. Multiline types SHOULD use the same hierarchy engine as expressions when their grammar has comparable precedence and grouping.

5.2.10. Modifiers And Annotations [META-MOD]

[META-MOD-01] Modifier and annotation order MUST be defined per declaration target. The ordering rule MUST specify relative order only and MUST NOT imply permission for grammatically or semantically invalid combinations.

5.2.11. Body Ownership [META-BODY]

[META-BODY-01] A named declaration, anonymous declaration, block expression, or control body MUST expose the ownership of its body. The profile MUST define opener placement, body indentation, empty-body form, closer placement, and the attachment of enclosing punctuation.

5.2.12. Controls [META-CONTROL]

[META-CONTROL-01] Each control header MUST establish a context separate from its body. Branches, case groups, match arms, handlers, and loop clauses MUST establish independent contexts to prevent alignment obligations from crossing unrelated control-flow paths.

[META-CONTROL-02] A profile MUST define when braces or equivalent block delimiters are mandatory, how chained branches or handlers join, how fallthrough is identified, and how control-transfer statements terminate.

5.2.13. Pipelines, Chains, And Dataflow [META-PIPE]

[META-PIPE-01] A pipeline, composition chain, or staged dataflow expression MUST preserve stage order and MUST treat each stage as 1 operand. Multiline stages SHOULD return to a common pipeline base after completing their internal context.

5.2.14. Embedding, Templates, Macros, And Preprocessors [META-EMBED]

[META-EMBED-01] Embedded languages, template regions, macro bodies, preprocessor continuations, and generated spans MUST identify which language grammar owns each area. A host-language alignment rule MUST NOT rewrite guest-language content without an explicit nested profile.

5.3. Comments And Documentation [META-COMMENT]

[META-COMMENT-01] A comment attached to a construct SHOULD move with that construct when formatting changes its position. Formatting MUST NOT make a comment appear to describe a different operand, branch, declaration, or list item.

[META-COMMENT-02] A trailing comment MUST NOT force unrelated lines into a shared alignment column. When it causes overflow or obscures ownership, it SHOULD become a preceding comment if that movement preserves its meaning and tool interpretation.

[META-COMMENT-03] Documentation comments, compiler directives, formatter controls, lint suppressions, and generated-region markers MUST retain the adjacency and shape required by their consumers.

5.4. Naming And Organization [META-ORG]

Naming, import ordering, member ordering, and file organization often vary more across languages and ecosystems than expression layout does. Nevertheless, rules governing them may belong in a language profile where applicable. Due to the inherent variety, universality is difficult, but not impossible:

[META-ORG-01] A profile MUST either define or explicitly delegate naming, import ordering, declaration ordering, file naming, and file organization. It MUST NOT infer conventions from examples alone.

[META-ORG-02] Reordering declarations, imports, fields, cases, mapping entries, or branches MUST preserve initialization order, lookup behavior, reflection order, visibility, side effects, and generated output.

6. Versions, Deprecations, And Compatibility [META-VERSION]

[META-VERSION-01] A profile MUST state its minimum, preferred, and maximum validated language versions or editions. Syntax unavailable at the minimum target MUST NOT be required without an explicit version-gated rule.

[META-VERSION-02] Deprecated lexical or grammatical forms MUST be governed by 1 centralized policy. Construct-specific sections SHOULD refer to that policy instead of duplicating its prohibitions and replacements.

[META-VERSION-03] A deprecation policy MUST distinguish deprecated syntax from deprecated APIs, runtime behavior, configuration, and tooling. It MUST identify the supported replacement and any case in which replacement may alter behavior.

[META-VERSION-04] A fixture whose explicit purpose is to detect deprecated or rejected syntax MAY contain that syntax only when isolated from production loading and marked as nonprecedential.

[META-VERSION-05] When a new language version adds syntax, the profile MUST update its language-facts table, token inventory, operator or delimiter tables, construct inventory, and validation fixtures before declaring the version supported.

7. Validation

7.1. Source Validation [META-VALIDATE]

[META-VALIDATE-01] Every normative syntax example in a language profile SHOULD be parsed or compiled by a supported implementation. Fragments that cannot stand alone MUST identify their assumed context or be embedded in a validation fixture.

[META-VALIDATE-02] Formatting validation MUST verify that the formatted program preserves parsing and behavior. Where practical, it SHOULD compare syntax trees, run semantic tests, or use another representation appropriate to the language.

[META-VALIDATE-03] Automated checks SHOULD cover:

duplicate and malformed rule identifiers;
unresolved rule references;
code fences;
tabs, trailing whitespace, and line limits;
parsing or compilation across supported versions;
warnings and deprecations selected by the profile;
formatter or linter agreement;
semantic regression tests; and
idempotence after repeated formatting.

[META-VALIDATE-04] A profile SHOULD include positive fixtures for compact and multiline forms, nested contexts, long protected units, comments, version-gated syntax, and each construct-specific exception. It SHOULD include negative fixtures for ambiguous, deprecated, or forbidden forms.

7.2. Rule Validation [META-AUDIT]

[META-AUDIT-01] Each rule MUST be testable or objectively reviewable. A rule that depends on judgment MUST name the decision boundary, such as line length, grammatical ownership, conceptual grouping, or semantic risk.

[META-AUDIT-02] Two rules MUST NOT independently own the same requirement. When requirements overlap, 1 rule MUST own the behavior and the others MUST reference it.

[META-AUDIT-03] A profile MUST be audited for contradictions among general rules, construct-specific exceptions, examples, formatter configuration, and supported versions.

[META-AUDIT-04] Optional alignment MUST have a bounded group and a deterministic escape for excessive padding. Optional formatting MUST NOT make conformance impossible to decide.

8. Maintenance [META-MAINT]

[META-MAINT-01] Rule identifiers MUST remain stable after publication. A retired identifier MUST NOT be reused for a different requirement; it SHOULD remain as a tombstone or migration note when external references may exist.

[META-MAINT-02] A rule change MUST update its examples, cross-references, fixtures, formatter configuration, and version notes in the same change.

[META-MAINT-03] A construct-specific rule that specializes or overrides a general rule MUST identify that general rule, state the grammar, tooling, or clarifying reason for the exception, and identify how the exception is validated. If it cannot identify a general rule, the author SHOULD first determine whether the missing concept belongs in the rules for general layout.

[META-MAINT-04] Examples SHOULD be minimal and nonduplicative. A canonical example SHOULD live with the rule that owns its behavior; worked examples elsewhere SHOULD demonstrate interaction among multiple rules.

[META-MAINT-05] A profile change SHOULD include a short rationale recording the grammar fact, ambiguity, maintenance concern, or language-version change that motivated it.

[META-MAINT-06] Mechanical migrations SHOULD be separated from semantic changes when practical. A formatting migration MUST NOT include unannounced behavior changes.

9. Language Profile Template

The following outline is nonnormative but provides a reusable starting point. A profile MAY rename or divide sections while preserving the required decisions.

# <Language And Dialect> Code Style

**Status:** <Draft Or Published> — <Version>
**Language target:** <Minimum Through Maximum>
**Formatter ownership:** <Tool And Version, Or None>

## 1. Scope And Conformance

### 1.1. Included Source
### 1.2. Excluded Source
### 1.3. Normative Language
### 1.4. Priorities
### 1.5. Version And Deprecation Policy

## 2. Lexical Profile

### 2.1. Style Tokens
### 2.2. Protected Source Units
### 2.3. Required Adjacency
### 2.4. Comments And Embedded Languages

## 3. Physical Layout

### 3.1. Whitespace And Indentation
### 3.2. Line Length
### 3.3. Structural And Alignment Bases
### 3.4. Operator Hierarchy
### 3.5. Break Propagation
### 3.6. Delimiter Matrix
### 3.7. List Policies

## 4. Construct-Specific Rules

### 4.1. Names, Access, And Suffixes
### 4.2. Calls And Construction
### 4.3. Declarations And Parameters
### 4.4. Callable Or Anonymous Forms
### 4.5. Literals And Destructuring
### 4.6. Types, Modifiers, And Annotations
### 4.7. Aggregate And Module Declarations
### 4.8. Operators And Assignments
### 4.9. Conditionals, Loops, And Matching
### 4.10. Errors, Handlers, And Transfers
### 4.11. Imports, Directives, And Metaprogramming

## 5. Naming And Organization

## 6. Validation Fixtures

## 7. Non-normative Worked Examples

9.1. Completion Criteria [META-COMP]

[META-COMP-01] A language profile is complete only when:

its scope and supported versions are explicit;
its language-facts, operator, delimiter, and construct inventories are populated;
every applicable construct family has an owning rule or explicit delegation;
every exception refers to its general rule, reason, and validation;
every rule identifier is unique and every reference resolves;
representative examples parse or compile;
deprecated and version-gated syntax is tested;
formatting is behavior-preserving and idempotent; and
required formatter, linter, and compiler versions are recorded.

1. Scope And Conformance [META-SCOPE]

1.1. Normative Language [META-NORM]