YINI Cheat Sheet

Based on the official YINI Specification (v1.0 Release Candidate 6)

A quick reference for writing clean, readable YINI configuration files.

Want to test a snippet while reading? Open the YINI Playground.

YINI makes data files (such as configuration files and application settings) easy for humans to read and predictable for machines to process — like INI, but with real structure, lists (arrays), objects, and comments.

More structured than INI, less noisy than JSON, and less fragile than YAML.

🧱 Basic Syntax

📝 Naming Rules

• Simple section names and keys should use normal identifier-like names.
• Use backticks for spaces, punctuation, special characters, or reserved-looking names:

^ `My App`
`api-key` = "abc123"
`user.name` = "Alex"

💡 Style Convention (Optional)

• Section names typically start with a capital letter, like: Title.
• Keys typically start with a lowercase letter, like: key.

This is a readability convention — not a requirement.

🔤 String Types

YINI strings are quoted and are raw by default.

Use normal raw strings for most values. Use C"..." or C"""...""" only when you need escape sequences.

🧩 Inline Objects & Nested Data

Objects are also called maps or dictionaries in many languages.

Simple object

db = { host: "localhost", port: 5432 }

Nested objects

service = {
    http: { port: 8080, secure: true },
    limits: { rpm: 1000 }
}

🧭 Important Rules

• Indentation is cosmetic — structure is defined by section markers (^, ^^, ^^^, etc.).

• Repeated section markers are supported up to level 9. For deeper nesting, use numeric shorthand such as ^10 DeepSection.

• Strings must be quoted using '...' or "...".

• Strings are raw by default. Use C"..." or c'...' only when you need escape sequences like \n or \t.

• key = value assigns a single value.

• Lists are assigned with = and square brackets, for example items = ["one", "two"].

• Trailing commas are allowed in lists and objects (lenient mode).

• Duplicate keys are disallowed by default.

• # starts a comment outside string literals.

• _ may be used as a visual separator in number literals and repeated section markers. It improves readability and does not change the value or section depth.

  maxUploadSize = 10_000_000

  Meaning: same as 10000000, but easier to read.

  ^^^_^^^_^^^ DeepSettings

  Meaning: same section depth (9 in this case) as ^^^^^^^^^ DeepSettings; the _ separators are only visual and do not count as section markers.

🔢 Number Formats

YINI supports multiple numeric formats:

All numeric forms are parsed as real numbers — no quotes required.

🧪 Example 1 — Minimal Real-World

^ App
name = "Nebula"
version = "2.3.1"

^^ Network
ports = [80, 443]
ssl = true   // boolean (case-insensitive)

^^ `Rate Limits`
requests = { perMinute: 1200, burst: 60 }
timeout = null

🧪 Example 2 — Practical Config with Comments

# Optional YINI marker
@yini

^ Service
name = 'Aurora'                 # Single quotes
message = C"Server started\nReady."   # C-string with newline escape
path = 'E:\Program Files\App'   # Backslashes are raw (no escaping needed)
enabled = Off                   # Boolean (case-insensitive)
retries = 3

    ^^ Database
    host = 'localhost'
    port = 5432
    color = 0x336699            # Hex number literal

    ; This is a full-line comment (for humans)
    --password = 'secret'       # Disabled line (ignored by parser)

        ^^^ Limits
        maxUsers = 1000
        timeout =               # Blank value → null (lenient mode)

💡 Strings:
Regular strings are raw by default.
Use C"..." or c'...' only when escape sequences are needed.

💡 Note:
Lines prefixed with -- are disabled configuration lines.
They behave like comments (the parser ignores them), but are intended to temporarily disable real configuration — not to serve as documentation.

In editors, they are typically highlighted differently from normal comments to indicate “disabled code” rather than explanatory text.