A clear and structured config format
By the YINI-lang project

YINI Cheat Sheet

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

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

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

ElementYINI Syntax
Section heading: level 1^ App
Section heading: level 2^^ Database
Section heading: level 3^^^ Pool
String"text", 'text', "C:\Users\Robin"
👉 Strings are raw by default — \ and \n are treated as normal text
👉 Use C"..." or c'...' for escape sequences like \n, \t, \\ (escapes are transformed during parse time)
Number42, 3.14, -10, 1e4
Booleantrue, false, on, off, yes, no (case-insensitive)
Nullnull, Null, (or blank in lenient mode)
List / Array[1, 2, 3]
Inline object (map/dict){ a: 1, b: 2 }
Comment// Default comment
Alt. comment# Comment (must be #␠ or #\t)

❌ #Missing space before comment start
✅ # This is an OK comment
Multi-line (block) comment/* comment */

/*
Multi-line
comment
*/
Full-line comment; This is a full-line comment (only full lines)
Disable line--debug = true

📝 Naming Rules

  • Section names and keys can include spaces.
  • Use backticks (`) for special characters or reserved words:
^ `My App`
`api-key` = "abc123"
`user.name` = "Alex"

💡 Style Convention (Optional)

  • Section names typically start with a Capital letter.
  • Keys typically start with a lowercase letter.

This is a readability convention — not a requirement.

🧩 Inline Objects & Nested Data

(Objects are also called maps or dictionaries in general sense.)

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.).
  • 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.
  • Inside a section, name: "John" creates a list.
    Use name = "John" for a single value.
  • Trailing commas are allowed in lists and objects (lenient mode).
  • Duplicate keys are disallowed by default.
  • # starts a comment only if followed by a space or tab.

🔢 Number Formats

YINI supports multiple numeric formats:

FormatExample
Integer42, -42

❌ 01 (leading zero not allowed)
✅ 1
✅ 0
Float3.14, -3.14

❌ 3,14
✅ 0.14
Scientific (base-10)1e6, 5.2E-3
Hexadecimal (base-16)#FFAA00

❌ # FFAA00 (parsed as a comment)
✅ #ffaa00
Binary (base-2)0b101010
Octal (base-8)0o755
Duodecimal (base-12)0z2BA9, 0z2EX9

Digits: 0–9, A or X = 10, B or E = 11 (case-insensitive)
💡 0z10 equals decimal 12.

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 = #336699             # 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.

Next Steps