PluginBench
Skill
Pass
Audit score 90

swift-style

johnrogers/claude-swift-engineering

Swift code style conventions for clean, readable, idiomatic code.

What is swift-style?

A style guide for writing consistent, maintainable Swift code. Use when writing Swift to ensure proper naming conventions, code organization, formatting, and idiomatic patterns that prioritize clarity and readability.

  • Defines naming conventions (UpperCamelCase for types, lowerCamelCase for everything else)
  • Establishes code organization patterns using extensions and MARK comments
  • Provides spacing and formatting rules (braces, blank lines, colons)
  • Guides memory management practices with weak self capture patterns
  • Explains access control best practices and when to use private vs public
  • Identifies common Swift mistakes and how to avoid them

How to install swift-style

npx skills add https://github.com/johnrogers/claude-swift-engineering --skill swift-style
Claude Code
Cursor
Windsurf
Cline

How to use swift-style

  1. 1.Review the Core Principles section (Clarity > Brevity > Consistency)
  2. 2.Apply naming conventions: UpperCamelCase for types/protocols, lowerCamelCase for variables/functions
  3. 3.Use the golden path pattern with early returns instead of nested conditionals
  4. 4.Organize code with extensions and MARK comments for protocol conformance
  5. 5.Follow spacing rules: same-line opening braces, one blank line between methods
  6. 6.Avoid self unless required by compiler
  7. 7.Use type inference where clear, explicit annotations for empty collections
  8. 8.Check against the Common Mistakes section during code review

Use cases

Good for
  • Ensuring consistent code style across a Swift team or project
  • Reviewing and refactoring existing Swift code for readability
  • Writing new Swift features with idiomatic patterns
  • Establishing project-wide naming and organization standards
  • Training developers on Swift best practices
Who it's for
  • Swift developers
  • iOS/macOS app developers
  • Teams establishing code standards
  • Code reviewers

swift-style FAQ

When should I use self in Swift code?

Avoid self unless required by the compiler. Only use it when necessary for clarity in capture semantics (like [weak self] in closures) or when the compiler requires it. Mixing self usage makes code harder to scan.

How should I organize code in a class with multiple protocol conformances?

Use extensions with MARK comments. Keep core implementation in the main class body, then add separate extensions for each protocol conformance, each marked with a MARK comment like '// MARK: - UITableViewDataSource'.

What abbreviations are allowed in Swift naming?

Only three universal abbreviations are allowed: URL, ID, and UUID. All other abbreviations should be spelled out (use 'configuration' instead of 'cfg', 'manager' instead of 'mgr', 'context' instead of 'ctx').

Should I use get in computed properties?

No. Omit the get keyword for read-only computed properties. Write the expression directly after the property name and opening brace.

How deep should I nest if/guard statements?

Avoid nesting. Use early returns and guards to keep the happy path left-aligned at the margin. This is called the golden path pattern and makes code easier to follow.

Full instructions (SKILL.md)

Source of truth, from johnrogers/claude-swift-engineering.


name: swift-style description: Swift code style conventions for clean, readable code. Use when writing Swift code to ensure consistent formatting, naming, organization, and idiomatic patterns.

Swift Style Guide

Code style conventions for clean, readable Swift code.

Core Principles

Clarity > Brevity > Consistency

Code should compile without warnings.

Naming

  • UpperCamelCase — Types, protocols
  • lowerCamelCase — Everything else
  • Clarity at call site
  • No abbreviations except universal (URL, ID)
// Preferred
let maximumWidgetCount = 100
func fetchUser(byID id: String) -> User

Golden Path

Left-hand margin is the happy path. Don't nest if statements.

// Preferred
func process(value: Int?) throws -> Result {
    guard let value = value else {
        throw ProcessError.nilValue
    }
    guard value > 0 else {
        throw ProcessError.invalidValue
    }
    return compute(value)
}

Code Organization

Use extensions and MARK comments:

class MyViewController: UIViewController {
    // Core implementation
}

// MARK: - UITableViewDataSource
extension MyViewController: UITableViewDataSource { }

Spacing

  • Braces open on same line, close on new line
  • One blank line between methods
  • Colon: no space before, one space after

Self

Avoid self unless required by compiler.

// Preferred
func configure() {
    backgroundColor = .systemBackground
}

Computed Properties

Omit get for read-only:

var diameter: Double {
    radius * 2
}

Closures

Trailing closure only for single closure parameter.

Type Inference

Let compiler infer when clear. For empty collections, use type annotation:

var names: [String] = []

Syntactic Sugar

// Preferred
var items: [String]
var cache: [String: Int]
var name: String?

Access Control

  • private over fileprivate
  • Don't add internal (it's the default)
  • Access control as leading specifier

Memory Management

resource.request().onComplete { [weak self] response in
    guard let self else { return }
    self.updateModel(response)
}

Comments

  • Explain why, not what
  • Use // or ///, avoid /* */
  • Keep up-to-date or delete

Constants

Use case-less enum for namespacing:

enum Math {
    static let pi = 3.14159
}

Common Mistakes

  1. Abbreviations beyond URL, ID, UUID — Abbreviations like cfg, mgr, ctx, desc hurt readability. Spell them out: configuration, manager, context, description. The three exceptions are URL, ID, UUID.

  2. Nested guard/if statements — Deep nesting makes code hard to follow. Use early returns and guards to keep the happy path left-aligned.

  3. Inconsistent self usage — Either always omit self (preferred) or always use it. Mixing makes code scanning harder and confuses capture semantics.

  4. Overly generic type namesManager, Handler, Helper, Coordinator are too vague. Names should explain responsibility: PaymentProcessor, EventDispatcher, ImageCache, NavigationCoordinator.

  5. Implied access control — Don't skip access control. Explicit private, public helps future maintainers understand module boundaries. internal is default, so omit it.