개발표준, Coding Standard, Coding Convention 등 한 사람이 짠 것 같은 통일성 있는 코드를 추구한다.
작가는 문장으로 말하고, 개발자는 코드로 말한다. 코드의 독자에게 잘 읽혀야 아름다운 코드라 할 수 있을 것 같이다.
코드도 SW생명 주기와 같이 만들어지고, 읽히고, 수정되고 하다가 더이상 수정할 수 없는 상태에 이므로 버려진다.
많은 Coding Convention들이 있지만, 이름 짓는 것만큼은 그리 실용적인 가이드가 많이 없다.
나의 작명법을 글로써 정리해 본다.
- 변수명과 함수명만으로 무슨 기능을 할지 추측이 가능하도록 각별히 공을 들인다.
이름만으로 추측이 안되는 코드를 보다 보면 그게 뭘 하는지 주렁주렁 주석이 달리기도 한다. 그렇게 주석을 주렁주렁 달라면 그 주석을 통째로 변수명, 함수명으로 쓰면 된다. ‘이 acb()라는 함수는 뭐하냐 함수야?’ 라 물었을 때 한문장으로 대답하기도 하기, 두세문장으로 대답하기도 한다. 한문장으로 설명되는 것은 함수 하나, 세문장이므로 함수 3개로 쪼개면 된다.
2. 변수명은 명사, 단 boolean type은 의문형으로
변수, 즉 Variable은 명사다. 그런데 그걸 동사로 쓰거나 형용사로 쓰면 해석을 어렵게 하게 만든다. 그리고 동사나 형용사로 이름을 지었다는 것은 뭔가 로직을 잘못 만들고 있음이 분명하다.
boolean type 변수는 대부분은 if 문에 쓰이는 것이므로, isXX, hasXX, shouldXX 로 한다.
if (isInitialized) …hasChildren && doSomething();assertTrue(shouldHTTPSAvailable)3. 함수명은 동사로 한다. 단 return type이 boolean 일 경우는 의문형
함수, 즉 function은 뭔가 동작을 하는 것으로 동사로 써야 한다.
array<List> fetchPatients()bool validateMember(…)bool isAvailableFire(…)4. 약어가 낀 합성어도 CamelCase, 단Class 명일 경우는 약어전체 대문자
CamelCase가 convention인 언어에서도 ‘ID’같은 약어들을 CamelCase 적용하지 않고 쓰는 경우가 많다. 이럴 경우 가독성이 떨어진다.
memberID (x) -> memberId (0)memberIDPerGroup (x) -> memberIdPerGroup (o)HTTPServer (o)IPAddress (o)5. manager, controller, value, type, case, get 이런 막연한 단어 지양
변수명을 value라고 쓰면 이게 뭔지 어떻게 해석할 수 있을까? 문맥을 다 봐야 그 변수가 뭘 담기 위한 것인지를 알 수 있다. 이렇게 있으나 마나한 변수명은 실제 담는 값에 맞게 제대로 작명해야 한다.
변수명, 함수명만 충분히 고민하고 지어도 코딩단계에서 왠만한 논리적인 오류는 제거할 수 있다.
6. RESTFul API명은 HTTP Spec에 맞게
URL은 Resource를 나타내는 것으로 다 명사여야 한다. 동사는 GET, POST, PUT, DELETE로 표현된다.
따라서 https://restfulapi.net/resource-naming/ 만 충실히 따르면 된다.
