Swift / 이름 짓기

📌 서론

iOS 개발자가 되기 위해 문득 기본적인 개발 규칙을 지키는 것이 중요하지 않을까 생각이 들었다.
그래서 가장 기본적인 내용이 되는 네이밍 규칙(Naming Convention)에 대해 작성하여 오래 기억할 수 있도록 하려고 한다.
네이밍 규칙을 일관성 있게 지키는 것은 코드의 가독성과 예측 가능성을 결정하는 핵심 요소이기 때문이다.

글의 목차는 아래와 같다.

• 카멜 케이스(Camel Case)
• 요소별 네이밍 규칙
• Swift API 디자인 가이드라인

---

🐫 카멜 케이스(Camel Case)

Swift 언어를 사용하여 개발을 할 때 가장 기본적으로 적용되는 규칙이다.
크게 두 가지 형태가 있는데, iOS 개발을 할 때는 주로 Lower Camel Case를 사용한다.

규칙	설명	예시
Lower Camel Case	첫 단어는 소문자, 이후 단어의 첫 글자는 대문자로 시작	myVariableName, getUserInfo
Upper Camel Case(Pascal case)	모든 단어의 첫 글자를 대문자로 시작	MyClass, UserModel

카멜 케이스는 문자의 형태가 마치 낙타 등에 난 혹과 같이 높낮이가 달라진다고 하여 카멜 케이스라고 한다고 한다.
거의 모든 iOS 개발에서 카멜 케이스를 사용하기 때문에 네이밍을 할 때 카멜 케이스를 사용하는 것을 습관화 해두면 좋다.

---

🎨 요소별 네이밍 규칙

다음은 각 요소별로 네이밍을 작성하는 방법이다. Swift를 사용한 개발을 할 때는 변수, 함수, 클래스, 구조체 등 다양한 코드를 작성하게 되는데, 이 때 네이밍 규칙을 이해하고 사용한다면 협업에서 큰 도움이 될 것이다.

1) 변수 및 상수

변수와 상수의 네이밍을 할 때는 명사 또는 명사구를 사용하여 네이밍을 하는 것이 좋다.
변수와 상수는 모두 코드에서 특정 값을 저장하는 역할을 한다. 때문에 동사나 형용사 같은 형태보다 명사의 형태를 취하는 것이 가독성 향상에 도움이 된다.

• let maximumCount = 10
• var currentBalance = 5000
• let items: [String]

2) 함수

함수의 네이밍을 할 때는 동사 또는 동사구를 사용하는 것이 좋다.
함수는 특정 행동을 정의하는 역할을 하기 때문에 get, request처럼 특정 행동을 포함하는 네이밍을 사용하면 가독성 향상에 도움이 된다.
또, 함수 호출 시점에서 마치 자연스러운 영어 문장처럼 읽히도록 네이밍을 하는 것이 Swift API 디자인의 핵심 원칙이기 때문에 이를 잘 고려하면 좋다.
(ex, tableView.reloadData())
특히 함수는 매개변수에 인자 레이블을 작성할 수 있기 때문에, 이를 활용하여 더욱 자연스러운 영어 문장이 되도록 만들면 좋다.

• func reloadData()
• func calculateTotal()
• func requestData(from url: URL)

Swift 네이밍에서 가장 중요한 부분 중 하나는 함수를 호출할 때이다. 규칙을 지키면 호출 구문이 주석 없이도 명확해지는데, 아래 예시들을 보면 알 수 있다.

첫 번째 인자 레이블 생략(또는 전치사 사용)

대부분의 경우, 첫 번째 인자 레이블은 생략하거나 전치사처럼 사용한다.

규칙	예시	이유
동사 + 명사	func update(color: UIColor)	함수 이름 update와 인자 이름 color를 합쳐 "색상을 업데이트 한다"는 자연스러운 구문이 된다.
전치사 삽입	func remove(at index: Int)	함수 이름 remove와 외부 레이블 at을 통해 "인덱스에서 제거한다"는 문장이 완성되어 가독성이 높아짐

후속 인자 레이블 명시

두 번째 이후의 모든 인자는 내부 이름과 외부 레이블을 모두 명시하여 매개변수가 무엇을 의미하는지 명확히 해야한다.

규칙	예시	이유
명환한 설명	func send(message: String, to recipient: User)	예를 들어 send(message: "안녕하세요", to: user)처럼 호출 시점에서 각 값이 어떤 역할을 하는지 즉각적으로 알 수 있게 되어 오류를 방지할 수 있음

3) 클래스 및 구조체

클래스 및 구조체는 Upper Camel Case로 네이밍을 한다.
이는 클래스와 구조체가 코드에서 새로운 유형(Type)의 정의를 나타내기 때문이며, 명사나 명사구 형태로 표현하기 때문에 변수나 상수 등과의 명확한 구분을 위해 Upper 형태로 작성한다.

• class Car
• struct UserInfo

4) 열거형

열거형도 클래스나 구조체처럼 Upper Camel Case를 사용한다.
한 가지 유의할 점은, 열거형의 네이밍은 Upper 형태를 사용하지만, 내부의 case는 Lower의 형태를 사용해야 한다는 점이다.

• enum NetworkError { case noInternet, serverDown }

5) 프로토콜

프토토콜 역시 클래스나 구조체처럼 Upper Camel Case를 사용한다.
다만, 프로토콜은 객체의 역할을 정의하거나 행동을 정의하는 역할이기 때문에 주로 어미에 -able, -ible 등의 접미사 형태로 표현한다.

• protocol ServiceConfigurable
• protocol Drawable

---

📏 Swift API 디자인 가이드라인 추천 사항

Apple은 Swift 코드를 더 자연스러운 영어 문장처럼 읽히도록 설계하기 위해 아래와 같은 구체적인 규칙을 권장한다.

1) 매개변수(파라미터) 이름 지정

함수 이름과 인자 레이블을 합쳤을 때, 마치 자연스러운 문장처럼 읽히도록 설계해야 한다.

목적	규칙	예시
값 변환	첫 번째 인자 레이블을 생략하여 자연스러운 구문을 만든다	let width = min(a, b) => a와 b의 최소값을 구함
값 생성	첫 번째 인자 앞에 전치사(e.g., wiht, from, of)를 사용하여 문장을 만든다	UIColor(red: 0.5, green: 0.3, blue: 0.8)
효과 또는 행동	첫 번째 인자에 동사를 포함한 설명을 넣는다	view.addSubview(button) => 버튼을 뷰에 추가

2) 약어(Abbreviation) 사용 금지

변수나 함수 이름에 축약어를 사용하지 않고, 전체 단어를 사용하는 것이 좋다.
축약어를 사용하게 되면 당장 코드는 짧아질 수 있겠지만, 해당 축약어를 모르는 개발자들에게 혼동을 줄 수 있으며, 코드 예측 가능성이 낮아지기 때문이다.

비추천	추천	이유
func cfgBtn()	func configureButton()	코드를 읽는 사람이 의미를 유추할 필요가 없도록 명확하게 작성
var usrName	var userName

3) 불리언 네이밍

불리언(Bool) 타입의 변수나 프로퍼티는 질문 형태나 형용사를 사용하여 이름만 보고도 ture/false 중 어떤 의미인지 알 수 있도록 한다.

• 추천(질문 형태): isDirectory, shouldAnimate, hasSuffix
• 비추천: isFinished (너무 광범위), status (불리언이 아닐 가능성이 높음)

---

✅ 결론

오늘은 Swift에서 기본적으로 지켜야할 네이밍 규칙에 대해 정리해 보았다.
버릇적으로 코드를 작성하고 있었는데, 규칙을 적다보니 잘 지키지 않던 규칙들도 보였다.
이번 정리를 통해 내가 어떤 부분을 놓치고 있었는지 알 수 있었고, 앞으로 개발을 하면서 해당 부분들을 고쳐나가볼 계획이다.