SwiftFormat?
- swift 코드 reformat을 위한 도구
- 코드 컨벤션 맞추기 작업을 컴파일 타임 이전에 자동으로 수행한다.
- 협업 과정에서 컨벤션 맞추기에 코드 리뷰 시간을 할애하지 않고, 한 사람이 쓴 듯한 일관성 있는 코드로 가독성을 높이기 위해 적용.
- 적용 과정에서 어떤 규칙을 적용할까 고민했고, 그 과정을 아래에 기록했다.
- 자세한 내용은 PR 참고
작업 중 고민점
- 주요한 고민점은 의견이 갈리는 규칙이 있을 경우 어떤 기준으로 채택하는가 였습니다.
- 기준은 아래와 같이 설정하였습니다.
- 가독성이 좋은가?
- 코드가 더 짧아지거나, 읽기 좋은 형태로 변환되는가?
- 우리가 읽기 편한 익숙한 개념인가?
- Swift가 추구하는 방향인가?
- Swift 버전이 상승하며 개선되는 방향인가?
타입 추론 vs 타입 명시
- 타입 추론이 더 느릴 줄 알았는데, 더 빠를 수도 있다는 사실을 알 수 있었습니다.
- 타입 추론 과정에서 알고리즘 처리 오버헤드가 있지만, 최적화가 계속되고 있습니다. 따라서 체감할 정도의 차이점이 있다고 보기는 어렵다고 합니다.
- 그리고 단순한 값 할당과 함께 변수를 선언할 땐 오히려 타입 추론이 더 빠를 수도 있습니다.
- 타입 명시일 때 지정한 타입과 비교하는 과정이 사라지기 때문!
- 다만 복잡해지는 expression의 경우엔 타입 추론이 오래 걸리거나 실패할 수 있습니다.
* 이 땐 expression 나누거나 타입 명시 방법을 사용하면 됩니다. - 결론적으로, 기본적으로는 타입 추론을 활용해 코드를 깔끔하게 유지하고, 필요한 경우 타입 명시를 사용하는 것이 좋겠다고 성규님과 의견을 모았습니다.
- 따라서 기본적으로 타입 추론을 사용하도록 포맷 규칙을 설정했습니다.
- 출처
익숙한 문법 vs 새로운 문법
- 몇 가지 포맷팅 규칙 중 낯선 문법들이 있었습니다.
- if let, guard let을 짧게 사용하는 문법은 Swift 5.7에서 지원하기 시작했습니다.
- 처음 보는 문법인 팀원도 있었지만, 익숙해지면 더 짧은 코드로 의미를 잘 나타낼 수 있다고 생각해 채택하였습니다.
- 또한 프로토콜을 준수하는 제네릭은 opaque 타입으로 치환될 수 있음은 낯선 개념이었습니다.
- 이렇게 하면 호출부, 구현부에서 추가적인 코드 작성이 필요없지만 동일한 성능과 동작을 한다는 장점에 모두 동의하여, opaque 타입을 더욱 공부하기로 하며 채택하였습니다.
- trailing comma 규칙도 저희에겐 낯선 개념이었습니다.
- 처음에는 콤마가 없는 것이 익숙하다고 생각했는데, SwiftFormat에서 콤마를 넣는 규칙을 제공하는 이유가 궁금해 조금 더 찾아봤습니다.
- 그 결과 trailing comma가 있을 경우 개발 과정에서 삶의 질(Quality of Life)가 향상된다는 Swift Proposal을 찾을 수 있었습니다.
Swift's support for trailing commas in array and dictionary literals makes it as easy to append, remove, reorder, or comment out the last element as any other element.
- 또한 해당 proposal이 제한적인 내용으로 받아들여졌음을 확인하였습니다.
- 따라서 개발 환경의 용이성을 높이고, Swift의 발전 방향과 일치한다고 생각해 채택하였습니다.
ios 개발자에용