본 글의 저작권과 원문은 https://blog.naver.com/sweetie_rex 에 있습니다.
현재의 글은 업데이트가 되지 않음을 유의해서 읽어주세요.
최신 업데이트 된 글을 읽으시려면 아래의 링크를 확인해주세요.
코드 작성 규칙들 (Coding Conventions)
여기까지 오느라 고생했어! 지금까지 배웠던 것들은 모두 프로그래밍의 기본중의 기본이야. 이런 기초적인 지식을 배웠으니 이제부터는 본격적으로 개발이라는걸 해봐야겠지?!
그 전에 지켜줘야 할 것들이 있어.
우리의 인생에는 '상식' 이라는게 있잖아.
국어사전에 따르면
'상식' 이란 사람들이 보통 알고 있거나 알아야 하는 지식. 일반적 견문과 함께 이해력, 판단력, 사리 분별 따위가 포함된다.
라고 설명되어 있는데, 우리가 코드를 작성함에 있어도 '상식' 이라는게 있어.
코드를 작성하는 규칙을 잘 지키는 것은 개발자들간에 상식이야. 이것을 'Coding Convention' 이라고 불러.
이전의 내용들을 보면, 변수명은 소문자(name, age, weight 등)로, 클래스는 첫글자가 대문자(Human, Student 등)로 시작하는 모습을 볼 수 있는데, 이런것들은 내가 그냥 쓰고싶은대로 쓴게 아니라, 모두 일반적인 코딩 컨벤션을 따랐던거야.
우리가 앞으로 코드를 작성하는데 이러한 컨벤션을 따르지 않는다면, 다른 개발자와 함께 협업하거나 회사에서 일할 때 '상식이 없는 사람' 취급을 받을수도 있어... 우리 열심히 공부했는데 바보취급은 받지 말아야겠지?
대표적인 코딩 컨벤션을 소개할게!
이름 규칙(Naming Rules) - 변수, 함수, 클래스, 메소드 등
이름을 짓는데는 대표적으로 5가지 방식이 있어. 네이밍 룰(Naming Rules) 이라고도 해.
- PascalCase (파스칼 케이스)
- 첫글자와 이어지는 단어의 첫글자를 대문자로 표기하는 방법
- 예)
GoodPerson,MyKakaoCake,IAmDeveloper - Pascal 이라는 프로그래밍 언어에서 이러한 표기법을 사용해서 유명해진 방식이야.
- camelCase (카멜 케이스)
- 첫단어는 소문자로 표기하지만, 이어지는 단어의 첫글자는 대문자로 표기하는 방법
- 예)
goodPerson,myKakaoCake,iAmDeveloper - 낙타(camel)의 등모양이 볼록한 것에 영감을 얻어서 이렇게 부르기로 했어.
- snake_case (스네이크 케이스)
- 모든 단어를 소문자로 표기하고, 단어를 언더바(_) 로 연결하는 방법
- 예)
good_person,my_kakao_cake,i_am_developer - 꼭 뱀(snake)이 땅을 기어다니는 것 같은 느낌이 들지않아?
- kebab-case (케밥 케이스)
- 모든 단어를 소문자로 표기하고, 단어를 대시(-) 로 연결하는 방법
- 예)
good-person,my-kakao-cake,i-am-developer - 꼬챙이에 큰 고깃덩어리가 꽂혀 있는 케밥(터키음식)의 이미지에서 영감을 얻어서 지은 이름이야. 명동의 길거리에 파는걸 자주 볼 수 있지.
- 이 방식은 프로그래밍에서는 잘 안쓰이고, 보통 파일명이나 폴더명을 만들때 사용하는 편이야. 코딩이 익숙해지고 개발자가 되면 파일과 폴더의 이름을 지정할 때, space(공백) 대신에 dash(-) 를 사용하는 자신을 발견하게 될거야. 대부분의 경우에서 이게 좋다는 사실을 깨닫게 되거든.
- UPPER_CASE (어퍼 케이스)
- 모든 단어를 대문자로 표기하고, 단어를 언더바(_) 로 연결하는 방법
- 예)
GOOD_PERSON,MY_KAKAO_CAKE,I_AM_DEVELOPER - 대부분의 프로그래밍에서 상수변수(constant variable)의 이름을 이렇게 사용하고 있어.
- 뭔가 소리치는 느낌과 매우 중요한 느낌이 들지.
이러한 case 들은 언어마다, 환경마다 조금씩 사용 사례가 달라지기도 하는데, Python / JavaScript & Java 기준으로 정리해보면 아래 표와 같아.
JavaScript 와 Java 는 코딩 컨벤션이 99% 동일한 편이라서 같이 묶었어. 이름값 하지?
| 구분 | Python | JavaScript & Java | 기타 |
|---|---|---|---|
| PascalCase | 클래스, Exception | 클래스, Exception | - |
| camelCase | - | 변수, 함수, 메소드 | - |
| snake_case | 변수, 함수, 메소드 | - | - |
| kebab-case | - | - | 파일, 폴더명 |
| UPPER_CASE | 상수변수 | 상수변수 | - |
이런 네이밍 룰 덕분에 우리는 앞글자가 대문자로 시작하는걸 본 순간, "아하, 이건 Class 이겠구나." 라고 본능적으로 눈치챌 수 있어.
Boolean 타입의 변수 작명규칙
위의 네이밍 룰에 이어서 boolean 타입의 독특한 변수명 작명 규칙이 있는데, 거의 보통 is 라는 접두사(prefix) 를 사용하는 편이야.
is_human = True # 사람인지 아닌지
is_animal = False # 동물인지 아닌지
is_exist = True # 존재하는지 안하는지
is_final_data = False # 마지막 데이터인지 아닌지
...이런 네이밍 룰 덕분에 우리는 is 라는 글자를 보는 순간, "아하, 이 변수는 boolean 타입의 변수겠구나. true/false 의 값을 가지겠구나." 라고 본능적으로 눈치챌 수 있어.
네이밍 룰은 기본중의 기본이니까 꼭 따르도록 하자!
들여쓰기 (indent)
들여쓰기(indent)는 2종류 방식으로 가능해.
- tab 방식
- space 방식
둘다 딱 보기엔 똑같이 빈칸으로 보이지만 실제 코드에서는 여러가지 이유로 space 사용이 권장되는 편이야.
그리고 들여쓰기의 칸 수를 2칸으로 할지, 4칸으로 할지, 8칸으로 할지도 다양하게 논의되는 편이지.
보통 적절한 가독성을 위해서 기본설정으로 4 space 를 즐겨 사용하는 편이야. 물론 나도 4 space 를 가장 좋아해서 이 책의 모든 코드는 4 space 를 기준으로 작성되어 있어.
위 2가지 외에도 아주 사소하게 들어가면
- 괄호를 사용하는 방법
- 괄호를 사용할지 안할지
- 띄어쓰기를 어떻게 할지
- comma 를 어느 위치에 찍을지
- 세미콜론을 사용할지 안할지
- 줄 간격을 어떻게 할지
- 줄 바꿈을 할지 안할지
- 주석을 어떤식으로 달지
- 작은따옴표(')를 사용할 건지, 큰따옴표(")를 사용할 건지
등등 따지고 들어가면 매우 다양하고 복잡하게 느껴질 수도 있지만, 지금은 이러한 것들이 있다는 사실만 알고 넘어가도 좋을 것 같아!
대부분의 프로그래밍 책들은 많은 사람들이 공통적으로 사용하는 방식을 채택하여 코드를 작성하기 때문에, 책을 많이 읽고 그에 따라 코딩하다보면 우리가 한국어를 체득하듯 자연스럽게 좋은 컨벤션을 따라하게 될거야. :-)
그런데.. 위와 같은 약속들을 일일히 생각하면서 코드를 작성하기엔 너무 괴롭다고?
그래서 개발자들을 위해서 만든 소스코드 분석도구가 있어. 바로 Lint 라는 녀석이야.
소스코드 분석도구 Lint
Lint 란, 소스코드의 잠재적인 오류를 확인하거나, 코딩 컨벤션을 쉽게 유지할 수 있도록 도와주는 도구야.
'Lint' 라는 단어는 옷에 자주 일어나는 '보푸라기' 라는 뜻이야. 옷에 보풀이 많으면 지저분해 보이잖아? 그래서 보풀제거기 같은 기계를 사용하기도 하지. 그 보풀제거기가 바로 Lint 야.
Lint 는 일관되고 읽기 쉬운 코드를 유지하는 데 도움을 주고, 개발자가 고려하지 못했던 오류를 포착하는 데 도움을 주기도 해.
대부분의 개발자들은 체계적이고 깨끗한 소스코드 관리를 위해 Lint 의 도움을 받으며 코드를 작성해.
Lint 는 위에서 설명한 모든 코딩 컨벤션들을 원하는대로 설정해서 자신의 스타일대로 코드를 작성하도록 도와줘. 공부하는 단계를 넘어서 실제 개발자가 된다면 모든 소스코드 작성에 Lint 를 잘 활용하는 것이 좋아.
거의 대부분의 언어에는 각 언어별 Lint(분석도구)가 있어.
Python 은 PyLint
JavaScript 는 ESLint
Java 는 CheckStyle 등이야.
Lint 에 대한 설정은 이 책에서 말하고자 하는 '프로그래밍의 본질' 은 아니기 때문에, 실제로 어떻게 사용할 수 있는지에 대해서는 설명하지 않을 거야. 오히려 자유로운 프로그래밍 공부를 방해할 가능성이 높으니 학습 단계에서는 사용하지 않는 것이 더 좋아. 지금은 그냥 "이런 도구가 있구나, 다음에 프로그래밍을 더 잘하게 되면 써봐야겠다." 정도로만 생각하고 넘어가면 아주 좋을 것 같아! :-)
