Swift Coding Practices
Application skill for Swift style learning (from the archived awesome-guidelines style capsules). For SwiftUI/UIKit/SPM layout, load stack capsules in skills/*-foundation.
Core Principle
Swift readability is clarity at the point of use, safe bindings, fluent names, grammatical argument labels, documented declarations.
When to Use / NOT
- Swift application/library/Package.swift modules, SwiftLint/SwiftFormat CI.
- Reviewing API names, labels, optionals, access control, docs.
NOT when:
- Non-Swift code.
- Generated Xcode project stubs, validate generators instead.
- Apple platform HIG-only UI, use platform foundation.
Workflow
- Safety & access, let, guard, optionals, struct/final (
swift-style-formatting-safety.md).
- Naming, roles, fluency, mutating pairs (
swift-style-naming-api.md).
- Labels, argument labels, defaults (
swift-style-argument-labels.md).
- Docs & types, summaries, methods vs functions (
swift-style-documentation-types.md).
- Verify, SwiftLint/SwiftFormat +
swift build / xcodebuild test on changed targets.
Red Flags
- Force-unwrap
! / IUO Type!
var when never mutated- Redundant type words in names (
removeElement)
- Missing
remove(at:)-style label when needed
- Method family overloads instead of defaults
- Public API without
/// summary
- Non-final class without subclass plan
- Overload on return type only
Verification
- SwiftLint/SwiftFormat on changed files
- Build + tests for touched modules
- Capsule checklist on public API review
References
awesome-guidelines/references/swift-style-learning-note.mdawesome-guidelines/references/swift-style-formatting-safety.mdawesome-guidelines/references/swift-style-naming-api.mdawesome-guidelines/references/swift-style-argument-labels.mdawesome-guidelines/references/swift-style-documentation-types.md
1---2name: swift-coding-practices3description: Use when authoring or reviewing Swift, let/guard/optionals, explicit access, struct/final defaults, API naming fluency, argument labels, defaulted parameters, and documentation summaries.4---56# Swift Coding Practices78Application skill for Swift style learning (from the archived `awesome-guidelines` style capsules). For SwiftUI/UIKit/SPM layout, load stack capsules in `skills/*-foundation`.910## Core Principle1112Swift readability is **clarity at the point of use**, safe bindings, fluent names, grammatical argument labels, documented declarations.1314## When to Use / NOT1516- Swift application/library/Package.swift modules, SwiftLint/SwiftFormat CI.17- Reviewing API names, labels, optionals, access control, docs.1819**NOT when:**2021- Non-Swift code.22- Generated Xcode project stubs, validate generators instead.23- Apple platform HIG-only UI, use platform foundation.2425## Workflow26271. **Safety & access**, let, guard, optionals, struct/final (`swift-style-formatting-safety.md`).282. **Naming**, roles, fluency, mutating pairs (`swift-style-naming-api.md`).293. **Labels**, argument labels, defaults (`swift-style-argument-labels.md`).304. **Docs & types**, summaries, methods vs functions (`swift-style-documentation-types.md`).315. **Verify**, SwiftLint/SwiftFormat + `swift build` / `xcodebuild test` on changed targets.3233## Red Flags3435- Force-unwrap `!` / IUO `Type!`36- `var` when never mutated37- Redundant type words in names (`removeElement`)38- Missing `remove(at:)`-style label when needed39- Method family overloads instead of defaults40- Public API without `///` summary41- Non-final class without subclass plan42- Overload on return type only4344## Verification4546- SwiftLint/SwiftFormat on changed files47- Build + tests for touched modules48- Capsule checklist on public API review495051## References5253- `awesome-guidelines/references/swift-style-learning-note.md`54- `awesome-guidelines/references/swift-style-formatting-safety.md`55- `awesome-guidelines/references/swift-style-naming-api.md`56- `awesome-guidelines/references/swift-style-argument-labels.md`57- `awesome-guidelines/references/swift-style-documentation-types.md`
ryan-brosas