Swift Coding Style Cheat Sheet (Version 1.0.1)

Compact version of the Swift Coding Style.

1. Scope

• The shared layout rules are summarized in the C Coding Style Cheat Sheet.
• This cheat sheet contains their Swift-specific form.

2. General Rules

• Comments and identifiers in English.
• Tabs for indentation (tab = 4 spaces). Spaces for alignment only.
• Max 80 characters including the line break, so max 79 visible source characters.
• Match neighboring Swift code when more than one form is allowed.

3. Imports and File Layout

• One import per line.
• Prefer the usual file order: header comment, imports, type or extension, MARK: sections, properties, functions.
• Use nested helper functions only when they are tightly local to one outer function.

4. Types, Extensions, and Modifiers

• Types and extensions keep modifiers on the same line.
• Use private static, never static private.
• Type and extension { stay on the same line.
• Prefer the same blank-line spacing between sections that neighboring Swift files use.

5. Properties and Other Stored Values

• Variables, constants, typealiases, and nested types keep modifiers on the same line.
• Use private static, never static private.
• Keep short computed properties on one line when they stay readable.
• Break after = when needed.
• Prefer breaking after = to breaking before another operator.
• Break before ?? when needed.

6. Functions and Initializers

• Function-level modifiers go on their own lines above func, init, subscript, or deinit.
• Keep modifier order normal.
• Keep static on its own line for functions.
• Function { goes on its own line.
• Return type may stay on the same line or break before ->.
• Parameters may break across lines like C function parameters.

7. Parameters, Generics, and Type Syntax

• Keep generic syntax compact and consistent with surrounding Swift code.
• Break wrapped generic parameter lists and constraints like other comma-separated lists.
• Prefer where only when it reads better than inline constraints.
• Keep attributes such as @objc on their own lines above the declaration they modify.

8. Control Flow

• Put { on the same line only when the control-flow head also ends on that line.
• If the control-flow head breaks, move { to its own line.
• Prefer early returns and early exits.
• One-line if forms are preferred when they stay simple and readable.
• Multi-statement branches use braces normally.

9. If and Guard Line Breaking

• Keep single-condition forms on one line when they fit.
• For broken condition lists, keep if or guard on the first line and indent following conditions one level.
• If the condition becomes visually heavy, if or guard may stand alone on its own line.
• Comma-separated condition lists break after commas.
• else may stay on the condition line or move to its own line.

10. Switch Statements

• Indent case and default one level inside switch.
• Indent the case body one more level.
• Keep simple cases on one line when they fit.
• If a case does not fit on one line, break after case and put the final : on the last pattern line.

11. Calls, Collections, and Closing Delimiters

• Break directly after (, [, or { when the expression is broken.
• Do not increase indentation again when breaking the same expression unless a sub-expression is broken.
• Closing delimiters may stand on their own lines to avoid decreasing indentation by two levels at once.
• Keep commas attached to the preceding element.

12. Return Statements and Expressions

• Return a simple single value directly when it fits.
• If the returned expression is complex, wrap it in ( ).
• Break before ?? when that produces the cleaner wrapped expression.
• Add parentheses where they improve readability.

13. Preference Rule

• Prefer the project's C-derived layout over generic Swift style guidance.