👋 매번 헷갈리는 naming conventions, 이제는 확실히 알고 넘어가자!
🔽 위 글은 해당 원문을 번역한 글로 오역이 있을 수 있습니다!
Naming Conventions For iOS Development by Samuel Hepditch
일관적이고 묘사적인 naming convetions을 따르는 것은 중요하지만 종종 간과되기도 한다. 학술 문헌에는 naming conventions이 프로그램에 대한 이해도를 높이고, 오류를 줄이는 것과 상관관계가 있다고 명시되어 있다.
게다가, 잘 명명된 클래스, 함수, 상수들은 개발자가 큰 파일을 훑어볼 때 최대한의 이해도를 끌어낼 수 있게 한다. 이를 통해 개발자는 기능을 신속하게 제공하거나 버그를 수정할 수 있고, 실수를 줄일 수 있다. 반대로 이름이 적절하지 않은 클래스나 함수는 그것의 용도를 정확히 설명하지 못해 버그가 많은 코드를 유발하고 때때로 이미 존재하는 기능을 중복 구현하게 되는 결과를 초래할 수도 있다.
따라서 naming convetions을 지키는 것은 중요한 일이다!
✏️ Principles of Effective Naming
✔️ Clarity always trumps brevity
항상 명확성이 간결성보다 중요하다.
이름이 긴 객체를 굳이 줄여쓸 필요는 없다! 전체 이름을 적어 용도를 명확히 전달해라!
😡 BAD : setAlpComp
😄 GOOD : setAlphaComponent
✔️ Each word in a name conveys indispensable information about a property, function or object.
이름의 각 단어들은 속성, 함수, 객체에 대한 필수적인 정보를 전달한다.
😡 BAD : priceArray.sortArray()
-> 속성의 이름이 이미 무엇이 정렬되는지 명시하고 있음
😄 GOOD : priceArray.sort()
✔️ Names should never be self referential.
이름은 절대 자기 자신을 참조하면 안된다.
😡 BAD : firstNameObject
😄 GOOD : firstName
✔️ All names are written in camelCase
모든 이름은 camelCase로 작성되어야 한다.
😡 BAD : maxselectedItems
😄 GOOD : maxSelectedItems
+) 아래의 경우는 보통 UpperCamelCase 를 사용한다. (대문자로 시작)
- Enumeration (열거형)
- Class (클래스)
- Structure (구조체)
- Protocol (프로토콜)
✏️ Naming Classes, Protocols, Methods and Properties
✔️ Classes
모든 클래스 이름은 클래스와 그것의 프로퍼티, 메소드들이 무엇을 달성하려고 하는지 명확히 설명해주는 명사를 포함해야 한다.
✔️ Protocol
(프로토콜 부분은 제가 개념이 부족해 혹시 해석이나 전달이 잘못될 우려가 있어 원문을 첨부하였습니다!)
Protocols are to be named based upon how they organize behaviours. A class which is the singular expression of a protocol should have the same name as the protocol it conforms to. However we can have protocols that enforce definitions on multiple classes. In this case, to ensure a protocol is not confused with a class it is a common convention to use the Gerund form (…ing).
프로토콜은 행동을 어떻게 조직화 하는지에 따라 이름이 정해져야 한다. 특정 프로토콜을 단일하게 구현하는 클래스는 그 프로토콜과 동일한 이름을 가져야 한다. 하지만 여러 클래스에 대해 정의를 강요하는 프로토로의 경우 클래스와 헷갈리지 않기 위해 관례적으로 -ing 형태를 사용한다.
✔️ Methods
Apple은 메소드 이름에 대한 여러 규칙들을 알리며 개발자가 이러한 원칙을 따라 App Store에 조금 더 신뢰할 수 있는 제품을 만들도록 권장하고 있다.
- 행동을 나타내는 메소드는 반드시 동사로 시작해야한다.
(ex. buildConstraints, displayLoadingIndicator) - do/does 와 같은 조동사는 메소드의 유용성을 명확히 설명하지 못하고 간결함을 해치므로 사용을 주의해야 한다.
- 부사나 형용사를 동사 앞에 놓는 것을 지양해야 한다.
- weak type parameter를 사용하는 경우, 매개변수 역할을 설명하는 명사를 그 앞에 붙여야 한다.
- 메소드가 사용된 곳에서 잘 작성된 문장처럼 읽힐 수 있도록 해야한다.
✔️ Properties
프로퍼티는 저장된 데이터의 기능을 기준으로 이름 지어야 하며, 데이터의 타입과는 관련이 없다. 프로퍼티 이름은 세 가지 형태로 구분될 수 있으며, 이는 모든 경우를 포괄한다.
- 명사형 (ex. phoneNumber)
- is + 형용사형 (ex. isHidden)
- 동사 + 객체형 (ex. dismissMenu)
개발자들은 종종 menuDismissed처럼 동사의 현재분사형을 사용하는데 이는 Apple의 권장사항과 맞지 않는다.
프로젝트를 진행할 때 이름이 잘 지어졌는지 확인하고 싶다면 주석이 필요한지 확인해봐라. 주석이 필요하다고 느껴진다면 시간을 내어 이름을 다시 짓는 것이 좋다. 좋은 이름은 주석이 불필요하게 만든다. 이미 이름을 붙인 것에 대해 더 나은 이름이 떠올랐다면 주저하지 말고 리펙토링해라. 너의 동료들이 이를 고마워할 것이다!
앞으로는 변수나 기타 등등 이름을 붙여야 할 상황이 있다면 한 번씩 더 생각하고 naming conventions 에 맞춰서 이름 지어야겠다 🤓 혹시 해석이나 틀린 내용이 있다면 언제든 댓글로 달아주세요 :)
