Swift 3.0 코딩 스타일 제안

2017-02-06
12 Views

이 내용은 Swift 3.0 코뎅을 효율적으로 진행하기 위해 다음 항목을 기준화해 보았다.

  • 개발자에 의한 기술 저하가 발행하지 않게 하자
  • 소스코드 의도가 명확하게 하자
  • 가독성을 최대한 떨어뜨리지 않고 간단한 설명으로도 관리가 되도록 한다
  • 이 내용을 통해 가독성 파악을 쉽게 유지할 수 있게

기본정책

생략할 수 있는 것은들은 기본적으로 생략한다. 이해하기 어려운 경우를 제외하고 설명을 최소화한다.

1. 네이밍(Naming)

1) 역할과 의도를 명확하게 알 수 있는 이름으로 구성한다

클래스, 메소드, 인스턴스 변수등은 이름만으로 역할과 의도가 이해할 수 있도록 해야 하며, 메소드의 변수등 범위가 짧은 변수는 생략된 이름을 사용해도 좋다.

2) 카멜케이스로 작성한다.

class, enum는 대문자로 작성하고, 메소드, 변수, 상수, 구조체 멤버는 소문자로 시작한다.

3) 접두사는 쓰지 않는다

암시적 네임스페이스가 설정되므로 접두사는 쓰지 않는다.

2. 자료형 (Types)

1) Optional형을 사용시 if let/guard let/Nil Coalescing Operator (a ?? b)를 사용한다

Forced Unwrap은 기본적으로 사용하지만 초기화시 값이 들어가는 IBOutlet등은 IUO(Implicitly Unwrapped Optional)속성을 사용할 수 있다.

2) 다운케스팅할 때 as?를 사용한다

as!를 기본적으로 사용하기 때문에 초기화시 값이 있는 경우 형이 보장되는 IBOutlet에 as!을 사용해도 좋다.

3. 클래스(Classes)

1) 속성, 메소드에 접근 self를 생략한다.

Xcode도구에서 색상으로 로컬변수와 구변하기 때문에 컴파일러에 지적된 경우에는 그렇지 않다.

2) 하위클래스에서는 delegate라는 속성을 정의하지 않는다

상위클래스에 delegate가 정의되어 있는 경우 문제가 발행하기 어렵게 되어 있기 때문이다.

3) ReadOnly속성에 get키워드는 사용하지 않는다

ReadOnly속성에는 get을 쓸 필요가 없기 때문이다.

4. 함수(Functions)

1) 메소드명 등에서 유추할 수 있는 경우, 레이블설명을 생략할 수 있다.

밑줄(_)을 작성하는 것으로 호출하는 쪽은 레이블 설명이 필요하지 않다.

2) internal은 생략하고 private, public은 명시한다.

public 메소드 override할경우나 internal로 끝나는 경우, public을 사용하지 않는다.

5 폐쇄(Closures)

1) 보다 줄여서 사용하는 방법을 채용한다

후행폐쇄(Trailing Closures)를 적극적으로 사용한다.

2) 폐쇄에서 self를 참조할 경우 약한 참조로 변경한다.

강한 참조상태면 순환 참조될 가능성이 있다

3) 폐쇄에서 인수를 사용하지 않으면 _에서 생략한다

6. 제어문(Control Flow)

1) guard문 사용한다.

nil체크등으로 빠른 메소드와 제어를 빠져나가게 할 경우 적극적으로 guard절을 사용한다.

2) 간단한 조건은 ()으로 둘러싸지 않는다

3) else는 if괄호와 같은 줄에 작성한다.

4) 복잡하지 않다면 삼항연산자를 사용하는 것을 추천한다

7. Enum

1) Enum을 사용할 경우 사용자정의명은 생략한다.

8. 주석(Comments)

1) 헤더 주석은 생략하자

클래스 헤더 및 메소드 헤더는 생략하고 명칭에서 역할이나 사용법을 이해할 수 있도록 작성하자. 설명을 추가할 경우에는 /* ~ */ 대신 ///을 사용하자.

2) MARK : 를 사용한다

MARK는 한줄로 위아래로 한줄 비운후 사용한다. delegate명 API파일 설명 스대로 사용하는 것을 권장하며 sub는 각자 늘린다.

3) TODO : 를 사용한다

개선할 부분이 있다는 의미에서 작성한다. 작업 실행과제와 연계한 내용을 넣을 필요는 없다.

4) FIXME : 조건부로 사용한다

작성 및 실제 작업하는 과제 번호등과 같이 작성한다. 작업에 사용하는 것은 자유지만 과제 번호없이 사용되면 병합되지 않는다.

9. 작성 형태 (Formatting)

1) 들여쓰기는 4칸씩 비워서 사용한다.

2) 중괄호는 클래스, 메소드, 제어문에 모두 사용한다.

3) 쉼표(,) 뒤에 곰백을 하나 넣는다.

4) 형 선언시 콜론은 공백없이 바로 사용후 공백하나를 넣는다

5) 제어문을 한줄으로 작성하는 경우 { 앞뒤와 } 앞에 공백하나씩 넣는다

6) 파일끝은 한개의 빈줄을 넣는다.

10. 디버그 로그(Debug logs)

1) 디버그 타겟에서만 실행하는 메소드를 정의하여 사용하자.

로그 관련 클래스 참고: https://swifter.kr/2017/02/03/swift-3-0%EA%B8%B0%EB%B0%98-%EB%A1%9C%EA%B7%B8-%ED%81%B4%EB%9E%98%EC%8A%A4/

11. 파일구조(File Structures)

1) protocol과 extension은 기본적으로 별도 파일로 만들자.

단, delegate등에만 사용하는 protocol은 해당 파일에 작성하며 사용자정의 클래스의 extension은 해당 파일에 작성한다.

12. 사용권장안함

개발시 사용하는 것은 상관없지만 중요한 부분에서는 사용하지 않기를 바란다.

1) assert()

2) CGRectMake()와 CGSizeMake()

CGRect, CGSize는 이니셜라이저를 사용하여 생성한다

3) 멀티바이트문자(한국어 및 이모티콘)으로 만드는 메소드명

 

참고자료

Facebook Comments

You may be interested

Xcode 기능 확장(Extension) 제거하기
Xcode
shares3 views
Xcode
shares3 views

Xcode 기능 확장(Extension) 제거하기

MJ Kim - 3월 18, 2017

Mac에서 Xcode Source Editor Extension등의 기능확장을 사용하다보면 디버깅시 시스템 환경 설정의 확장이 앱에 등록되는 경우가 있다. 계속해서 목록이 남아 있기…

iOS App Store Review(앱 심사약관) 번역
Swift 3.0
shares109 views
Swift 3.0
shares109 views

iOS App Store Review(앱 심사약관) 번역

MJ Kim - 3월 15, 2017

App Store Review를 번역했다. 사실 이번에 좀 애매한 리젝을 당해서 그걸 이해하고자 정리해본다. 원문링크: https://developer.apple.com/app-store/review/guidelines/ 1. 이약관은? 1.1 앱 개발자로서 프로그램의…

Raspberry Pi 타이머 On/Off 전원제어모듈 RPi1114-Raspberry Pi
IoT by Raspberry Pi
shares7 views
IoT by Raspberry Pi
shares7 views

Raspberry Pi 타이머 On/Off 전원제어모듈 RPi1114-Raspberry Pi

MJ Kim - 3월 04, 2017

RPi1114-Raspberry Pi전원제어 모듈이 있다. 이 제품은 40Pin GPIO핀헤더에 연결하여 사용하는 모듈로 Cortax-M0마이크로컨트롤러 LPC1114를 내장하고 Raspberry Pi의 시작과 정지 순서등을 프로그래밍할…