---
# System prepended metadata

title: Points to check

---

# Main Points to Check for iOS Dev
## General
- [ ] Ensure that TODO titles in your commits are clear enough for others to understand the task from the titles alone. Follow this format for TODOs: `// TODO: GITHUB_ISSUE_LINK - GITHUB_ISSUE_TITLE.`.
- [ ] Add comments if some parts of the code are difficult to understand on its own, or when using uncommon techniques or ideas that require further explanation.
  ::: spoiler Guidelines for comments
    Please follow the guidelines as follows.
    - `///` : Use `///` for Documentation comments
    - `//` : Use `//` for Non-Documentation Comments
    - `/** ... */` : Not permitted to use
    - `/* ... */`: Not permitted to use
    
    Reference: [Swift Style Guide](https://google.github.io/swift/#non-documentation-comments)
  :::
- [ ] Always add a TODO comment to any sections that may need future revisions.
- [ ] Avoid using magic numbers.
- [ ] Rebase your current brunch onto the main brunch before pushing your commits.


 
## iOS Development
This checklist outlines the main points to check during iOS app development. Always double-check these points before pushing your commits to ensure a smoother review process. If you identify additional important points, feel free to contact Takaya Shirai to update this checklist! You can also create your own checklist for minor mistakes you frequently make.

### Check list

- [ ] Follow the [Swift Style Guide](https://google.github.io/swift/#non-documentation-comments).
    ::: spoiler Example
    Follow the [Delegation Methods Guide](https://google.github.io/swift/#delegate-methods), when you name methods on delegate protocols and delegate-like protocols.
    :::
- [ ] Use `LayoutConstant` and `LocalizedString` where applicable.
    ::: spoiler Example
    LayoutConstant: https://github.com/search?q=repo%3Aokuda-seminar%2FTwitter-Clone%20LayoutConstant&type=code
    LocalizedString: https://github.com/search?q=repo%3Aokuda-seminar%2FTwitter-Clone%20LocalizedString&type=code
    :::
- [ ] Ensure you use `swift-format -r . -i`. If you haven't installed the swift-format yet,  install it [here](https://github.com/swiftlang/swift-format).
- [ ] When you add new files, sort them by name before commiting.
- [ ] Use `lazy` if there’s a significant computational setup. It can reduce computational overhead.
- [ ] Use `@ViewBuilder` to make the view hierarchy easier to understand.
    ::: spoiler Example
    You can seperate the entire view content into subViews such as Header() or Tabs() using @ViewBulder, and create each subView seperately. This makes the view hierarchy easier to understand as shown in the below example.
        
        struct IntroductionView: View {
          var body: some View {
            // the view hierarchy easy to understand
            VStack {
              Header()
              IntroductionMainPart()
              IntroductionSubPart()
            }
          }
            
          @Viewbuilder
          private func Header() -> some View {
            // Header View Content
          }
            
          @Viewbuider
          private func IntroductionMainPart() -> some View {
            // IntroductionMainPart View Content
          }
          
          @Viewbuider
          private func IntroductionSubPart() -> some View {
            // IntroductionSubPart View Content
          }
        }
    :::
- [ ] Please use `[weak self]` in a closure to avoid a retain cycle and memory leaks
 → [What is a retain cycle?](https://vinodhswamy.medium.com/strong-cycle-retain-cycle-in-swift-f452f07518b2)
    ::: spoiler When you want to use self?.X() multiple times in one closure 
    When you need to call self?.X() multiple times within a closure, you should define a seperate function outside the closure. This approach ensures that all lines within the closure are executed. Otherwise, if one function deallocates the class instance, the other functions may not execute. Below are examples that demonstrate this issue. 

        - Good Example
        In this approach, a single function (XFunction()) is called within the closure. 
        This ensures the entire process (calling Y() and Z()) is completed.
        
        XViewObserver.XCompletion = { [weak self] in
          self?.XFunction()
        }
        
        private func XFunction() {
          Y()
          Z()
        }
        
        - Bad Example
        In this example, calling self?.Y() and self?.Z() separately can result in 
        only partial execution. If self is deallocated after Y() is called,
        then Z() will never be executed.

        XViewObserver.XCompletion = { [weak self] in
          self?.Y()
          self?.Z()
        }
        
    :::
- [ ] Don't import private packages (e.g import _PhotosUI_SwiftUI). It is an anti-pattern and Apple could block launching apps that include them.
