[iOS] - Swift Style Guide 정리

회사에서 항상 고려해야하지만 마음대로 잘 안되는 것이 바로 코딩 스타일, 컨벤션..?이 있겠다.

실제로 이런 사항을 항상 코드 리뷰 때 지적을 받는다.

 

오늘은 jinnify님의 블로그에 정리가 잘되어있어서 보고 정리해보려고 한다.

출처
github.com/raywenderlich/swift-style-guide#function-calls

jinnify.tistory.com/57

[Swift] Swift Style Guide 정리

---

1. Naming

클린 코드에 나온 내용들이겠지만 그래도 한번 보도록 해보장.

 

1. Striving for clarity at the call site

-> 사용하는 곳에 명확하게 이해 할 수 있게끔 이름을 만들자.

2. prioritizing clarity over brevity

-> 간결함보다는 명료함

3. using camel case(not snake case)
-> 카멜 케이스를 사용해라. (카멜 규칙을 사용하라는 듯)

4. using uppercase for types (and protocols). lowercase for everything else
-> 타입이나 프로토콜은 UpperCamelCase를 따르고 그 외에는 lowerCamel Case를 따른다.

(카멜 규칙대로 클래스나 프로토콜은 대문자로 시작이고 그외는 소문자.. ㅎ)

5. including all needed words while omitting needless words
->불필요한 말은 생략하고 필요한 말들은 모두 포함하라.

6. using names based on roles, not types

-> 타입이 아니라 기능에 기반한 이름을 사용

7. beginning factory methods with make

- 팩토리 메서드는 make라는 이름으로 시작한다.

8. side effects에 대한 메서드 이름 지정

- 써주신 글을 이해해보자면 mutating 함수는 명사형 동사를 쓰고 nonMutating 함수는 ed, ing을 붙인다.

예시로 sort와 append를 주셨다.

9. using terms that don`t surprise experts or confuse beginners

-> 전문가를 놀라게하거나 초보자에게 혼동을 주지 않는 용어 사용(쉬운 말만 쓰라는 뜻)

10. generally avoiding abbreviations

-> 일반적으로 약어를 피한다.

11. using precedent for names

-> 이름에 대해 선례를 사용한다.(기존 문화를 따르라는 뜻)

12. preferring methods and properties to free functions

-> free function 대신 Method와 Properties를 선호해라.

 

 

* function과 Method의 차이점

옛날에 공부했던 것인데 간단하게 정리하자면 Class와 Struct, Enum에 속해 있는 것은 메서드 아닌 것은 펑션이다.

 

13. avoiding overloads on return type

-> 반환 타입에 대한 오버로딩을 피해라 라는 의미

오버로딩을 쓰는 것은 구별하기 어렵고 혼동의 원인이 된다고 한다.
(최대한 안쓰는게 좋다는 뜻)

 

14. taking advantage of default parameters

-> 기본 매개변수의 장점 활용하기

 

15. choosing good parameter names that serve as documentation

-> 좋은 파라미터 이름을 선택해야 된다.

 

 

산문(Prose)

산문이 뭐지..?

메소드 이름을 참조하는 그런 것인가 보다.

1. 메개변수 없이 메소드 이름으로 작성한다.

 -> addTargat

2. 인자 레이블을 가지는 메소드 이름을 작성한다.

-> addTarget(_: action:)

3. 인자 레이블과 타입을 가지는 메소드 전체 이름을 작성한다.

-> addTarget(_: Any?, action: Selector?)

 

 

클래스 접두사(Class Prefixes)

Swift 타입은 모듈에 의해 자동적으로 namespaced가 포함된다.

RW(RW가 뭐지..?)처럼 클래스 접두사를 추가하지 않아야한다.

혼동 스러울 경우에만 모듈의 이름을 지정해서 구분해준다.

import SomeModule
let myClass = MyModules.UsefulClass()

 

델리게이트(Delegates)

델리게이트 메서드를 만들 때 이름이 없는 첫 번째 매개변수는 델리게이트 이름이어야한다.

(응?? 첫번째 매개 변수 이름을 델리게이트 이름으로 써야한다고?? 뭐지..? 이해가 잘.. )

 

제네릭(Generics)

제네릭 타입을 실제로 구현해서 해본적은 아직 잘 없는 것 같다.. 어려워..

아무튼 제네릭 타입은 대분자 카멜 표기법으로 서술해야한다.

쓸 의미나 규칙이 없다면 T, U, V 중 하나를 사용한다.

 

 

2. 코드 구성(Code Organization)

1. Protocol Conformance

Extension을 사용하여 코드를 논리적 기능 블록으로 구성하라.

주석을 사용할 때 //Mark: - 를 사용하여 코드를 분리하라는 뜻과 extension을 자주 사용하여 깔끔하게 구분하라는 의미

이건 중요한 것 같다. extention을 delegate 구현할 때 잘 해보자.

 

2. 사용되지 않는 코드(Unused Code)

사용하지 않는 주석된 코드는 지우자. 튜토리얼 등등...그런 코드들

회사에서도 이런 주석들이 있는데 다음에 사용하거나 원복하려고 주석된 코드들이 있다.

음... 유용하게 쓰일 때가 있긴한데 ..ㅋㅋㅋㅋ

 

3. Imports를 최소화하기 (Minimal Imports)

중복된 프레임워크는 여러번 호출 할 필요가 없다.

Fondation을 하면 UiKit을 안해도되는 뭐 그런거??

 

3. 주석(Comments)

주석은 반드시 최신 상태로 유지하거나 삭제되어야한다.

코드와 함께있는 인라인 주석은 피해야한다. /* */ 주석은 피하라고 되어있네..

 

4. 클래스와 구조체(Classes and Structures)

 

1. Self 사용하기(Use of Self)

간결함을 위해, Swift는 객체의 프로퍼티에 접근하거나 메서드 호출할 필요할 필요가 없는 경우에 self 사용을 피해야한다.

 컴파일러에 의해 요구 될 때만 self를 사용한다.

self 없이 컴파일하는 경우에 생략한다.

 

2. 연산 프로퍼티(Computed Properties)

간결함을 위해 읽기전용인 경우 get을 생략하고 get과 set이 필요할 때만 사용된다.

 

3. Final

final의 사용은 가끔씩 의도를 명확하게 해주고 가치가 있다.

final은 상속이나 재정의를 막는 클래스 수식어