2.6 KiB
Repository Guidelines
Project Structure & Module Organization
The SwiftUI application lives in Cable/, with CableApp.swift bootstrapping shared state and the scene hierarchy. Feature views such as CalculatorView, SystemEditorView, and LoadEditorView sit beside their supporting models (CableCalculator, UnitSystem, Item). Shared assets are stored in Assets.xcassets, while entitlement and configuration files remain at the top level. Unit tests reside in CableTests/ and UI automation in CableUITests/; mirror new feature code with corresponding test folders.
Build, Test, and Development Commands
Work in Xcode 15 or newer targeting the iOS 17 simulator. Use open Cable.xcodeproj to launch the project with the correct scheme configuration. From the command line, xcodebuild -scheme Cable -destination 'platform=iOS Simulator,name=iPhone 15' build performs a debug build, and xcodebuild -scheme Cable -destination 'platform=iOS Simulator,name=iPhone 15' test runs both unit and UI test bundles. Prefer running through Xcode when iterating on UI so previews and Instruments remain available.
Coding Style & Naming Conventions
Follow idiomatic Swift style: four-space indentation, trailing commas for multiline collections, and 120-character soft line limits. Types use UpperCamelCase, methods and properties use lowerCamelCase, and tests follow testScenario_expectedResult. Keep SwiftUI view files focused on a single view struct, extracting supporting types or extensions into adjacent files when logic grows. Rely on Xcode's "Re-Indent" and "Add Missing Conformance" tools for quick formatting passes before reviews.
Testing Guidelines
CableTests.swift demonstrates standard XCTest usage; add focused test cases that cover each calculator branch and unit conversion rule you touch. Place UI flows that require navigation assertions in CableUITests/, reusing launch helpers from CableUITestsLaunchTests. Run xcodebuild ... test (above) or the Test action in Xcode before submitting changes. Aim to keep or raise coverage for core calculation logic when introducing new units or system behaviors.
Commit & Pull Request Guidelines
Existing history favors short, descriptive subjects (e.g., systems first); continue with concise, imperative summaries under 50 characters, adding optional bodies when context is needed. Group unrelated work into separate commits to keep diffs reviewable. Pull requests should link related issues, summarize functional changes, call out impacted screens, and attach simulator screenshots for major UI updates. Mention any follow-up tasks or technical debt explicitly in the PR description.