|
| 1 | +# Code Style and Conventions |
| 2 | + |
| 3 | +## Formatting Rules |
| 4 | + |
| 5 | +The project uses **SwiftFormat** with a specific configuration defined in `BuildTools/.swiftformat`. |
| 6 | + |
| 7 | +### Active SwiftFormat Rules |
| 8 | +- `isEmpty` - Prefer `.isEmpty` over `.count == 0` |
| 9 | +- `preferCountWhere` - Prefer `count(where:)` over `filter().count` |
| 10 | +- `redundantExtensionACL` - Remove redundant access control in extensions |
| 11 | +- `modifierOrder` - Consistent ordering of declaration modifiers |
| 12 | +- `consecutiveBlankLines` - Remove consecutive blank lines |
| 13 | +- `blankLineAfterImports` - Add blank line after imports |
| 14 | +- `andOperator` - Use `&&` instead of `,` in conditions |
| 15 | +- `elseOnSameLine` - Place `else` on same line as closing brace |
| 16 | +- `fileHeader` - Standardize file headers |
| 17 | +- `hoistPatternLet` - Hoist pattern let bindings |
| 18 | +- `leadingDelimiters` - Consistent leading delimiter placement |
| 19 | +- `modifiersOnSameLine` - Keep modifiers on same line |
| 20 | +- `preferKeyPath` - Prefer key paths where possible |
| 21 | +- `redundantInternal` - Remove redundant `internal` keyword |
| 22 | + |
| 23 | +### Automatic Formatting |
| 24 | + |
| 25 | +The project uses a **pre-commit hook** that automatically formats code before each commit: |
| 26 | + |
| 27 | +```bash |
| 28 | +# Install the hook (run once) |
| 29 | +make hook |
| 30 | +``` |
| 31 | + |
| 32 | +The hook runs SwiftFormat on staged Swift files using `git-format-staged.sh`. |
| 33 | + |
| 34 | +## Swift Style Guidelines |
| 35 | + |
| 36 | +### General Principles |
| 37 | +- Write clear, readable code |
| 38 | +- Use descriptive variable and function names |
| 39 | +- Add documentation for public APIs |
| 40 | +- Follow Swift API Design Guidelines |
| 41 | +- Maintain consistency with existing code patterns |
| 42 | + |
| 43 | +### File Organization |
| 44 | +- Import statements at the top |
| 45 | +- Blank line after imports |
| 46 | +- Group related functionality together |
| 47 | +- Use `// MARK: -` comments for section organization |
| 48 | + |
| 49 | +### Access Control |
| 50 | +- Use the most restrictive access level possible |
| 51 | +- Default to `internal` when appropriate |
| 52 | +- Mark public APIs explicitly |
| 53 | +- Use `private` and `fileprivate` for implementation details |
| 54 | + |
| 55 | +### Naming Conventions |
| 56 | +- Use descriptive names that convey purpose |
| 57 | +- Follow Swift naming conventions: |
| 58 | + - Types: `PascalCase` |
| 59 | + - Functions, properties, variables: `camelCase` |
| 60 | + - Constants: `camelCase` (not SCREAMING_SNAKE_CASE) |
| 61 | + |
| 62 | +## Git Conventions |
| 63 | + |
| 64 | +### Branch Naming |
| 65 | +Follow the pattern: `<initials>/<type>/<description>` |
| 66 | +- `ov/fix/xxx` - Bug fixes |
| 67 | +- `ov/refactor/xxx` - Refactoring work |
| 68 | +- `ov/feat/xxx` - New features |
| 69 | + |
| 70 | +### Commit Messages |
| 71 | +Follow the **50/72 rule**: |
| 72 | + |
| 73 | +**Subject line (50 chars max):** |
| 74 | +``` |
| 75 | +type: Brief description in imperative mood |
| 76 | +``` |
| 77 | + |
| 78 | +**Body (wrap at 72 chars):** |
| 79 | +``` |
| 80 | +Explain what changes were made and why (not how). |
| 81 | +Include any relevant context or reasoning. |
| 82 | +
|
| 83 | +Reference issue numbers if applicable. |
| 84 | +``` |
| 85 | + |
| 86 | +**Types:** |
| 87 | +- `feat:` - New feature |
| 88 | +- `fix:` - Bug fix |
| 89 | +- `refactor:` - Code refactoring |
| 90 | +- `test:` - Adding or updating tests |
| 91 | +- `docs:` - Documentation changes |
| 92 | +- `chore:` - Build process, dependency updates |
| 93 | +- `perf:` - Performance improvements |
| 94 | + |
| 95 | +**Examples:** |
| 96 | +``` |
| 97 | +refactor: Remove PromiseKit from Apple Pay components |
| 98 | +
|
| 99 | +Replace PromiseKit with native async/await for better |
| 100 | +maintainability and to reduce dependencies. |
| 101 | +``` |
| 102 | + |
| 103 | +``` |
| 104 | +fix: Correct 3DS authentication flow for Safari |
| 105 | +
|
| 106 | +The 3DS window was not properly handling Safari's security |
| 107 | +restrictions. This adjusts the flow to use SFSafariViewController |
| 108 | +consistently. |
| 109 | +``` |
| 110 | + |
| 111 | +### Important Rules |
| 112 | +- **Do NOT mention Claude/AI assistance** in commit messages |
| 113 | +- Use imperative mood ("Add feature" not "Added feature") |
| 114 | +- Focus on what and why, not how |
| 115 | +- Keep subject line under 50 characters |
| 116 | +- Separate subject from body with blank line |
| 117 | +- Wrap body at 72 characters |
| 118 | + |
| 119 | +## Code Review Guidelines |
| 120 | + |
| 121 | +- Focus on code clarity and maintainability |
| 122 | +- Ensure tests are included for new features |
| 123 | +- Check for proper error handling |
| 124 | +- Verify PCI compliance for payment-related code |
| 125 | +- Review for potential memory leaks |
| 126 | +- Ensure accessibility is maintained |
| 127 | +- Check that UI updates happen on main thread |
0 commit comments