우리의 약속, 코드 컨벤션 (Coding Conventions)과 보풀 제거기 Lint

 

 

우리의 인생에는 '상식' 이라는게 있다. 국어사전에 따르면

 

 

'상식' 이란 사람들이 보통 알고 있거나 알아야 하는 지식.
일반적 견문과 함께 이해력, 판단력, 사리 분별 따위가 포함된다.

 

 

 

라고 설명되어 있는데, 우리가 코드를 작성함에 있어도 '상식' 이라는게 있다.

 

코드를 작성하는 규칙을 잘 지키는 것은 개발자들간에 상식이다. 이것을 'Coding Convention' 이라고 부르는 것이다.

대부분의 코드를 보다보면 변수명은 소문자(name, age, weight 등)로, 클래스는 첫글자가 대문자(Human, Student 등)로 시작하는 모습을 볼 수 있는데, 이런것들은 내가 그냥 쓰고싶은대로 쓴게 아니라, 모두 일반적인 코딩 컨벤션을 따른 것이다.

우리가 앞으로 코드를 작성하는데 이러한 컨벤션을 따르지 않는다면, 다른 개발자와 함께 협업하거나 회사에서 일할 때 '상식이 없는 사람' 취급을 받을수도 있다...

 

열심히 공부했는데 바보취급은 받지 말아야겠죠? 

 

---

 

코드 작성 규칙들 (Coding Conventions)

 

이름 규칙(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 기준으로 정리해보면 아래 표와 같습니다.

 

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 를 즐겨 사용하는 편인 것 같다. 

 

위 2가지 외에도 아주 사소하게 들어가면

• 괄호를 사용하는 방법
• 괄호를 사용할지 안할지
• 띄어쓰기를 어떻게 할지
• comma 를 어느 위치에 찍을지
• 세미콜론을 사용할지 안할지
• 줄 간격을 어떻게 할지
• 줄 바꿈을 할지 안할지
• 주석을 어떤식으로 달지
• 작은따옴표(')를 사용할 건지, 큰따옴표(")를 사용할 건지

등등 따지고 들어가면 매우 다양하다.

 

대부분의 프로그래밍 책들은 많은 사람들이 공통적으로 사용하는 방식을 채택하여 코드를 작성하기 때문에, 책을 많이 읽고 그에 따라 코딩하다보면 우리가 한국어를 체득하듯 자연스럽게 좋은 컨벤션을 따라하게 된다.

 

그런데.. 위와 같은 약속들을 일일히 생각하면서 코드를 작성하기엔 너무 괴롭지 않나요..?

 

그래서 개발자들을 위해서 만든 소스코드 분석도구가 있다. 바로 Lint 라는 녀석.

 

소스코드 분석도구 Lint

Lint 란, 소스코드의 잠재적인 오류를 확인하거나, 코딩 컨벤션을 쉽게 유지할 수 있도록 도와주는 도구로 'Lint' 라는 단어는 옷에 자주 일어나는 '보푸라기' 라는 뜻이다. 옷에 보풀이 많으면 지저분해 보이잖아요? 그래서 보풀제거기 같은 기계를 사용하기도 하지. 그 보풀제거기가 바로 Lint!!!

 

Lint 는 일관되고 읽기 쉬운 코드를 유지하는 데 도움을 주고, 개발자가 고려하지 못했던 오류를 포착하는 데 도움을 주기도 한다. 대부분의 개발자들은 체계적이고 깨끗한 소스코드 관리를 위해 Lint 의 도움을 받으며 코드를 작성하게 되는데 Lint 는 위에서 설명한 모든 코딩 컨벤션들을 원하는대로 설정해서 자신의 스타일대로 코드를 작성하도록 도와준다.

 

공부하는 단계를 넘어서 실제 개발자가 된다면 모든 소스코드 작성에 Lint 를 잘 활용하는 것이 좋으니 꼭 알아둘 것을 권장한다. 거의 대부분의 언어에는 각 언어별 Lint(분석도구)가 있으니 본인이 사용하는 언어에 맞는 Lint를 사용하면 된다.

 

Python 은 PyLint

JavaScript 는 ESLint

Java 는 CheckStyle 등

 

 

Lint를 적용하는 방법을 기술한 블로그들은 많으니, 스스로 찾아보는 것도 큰 도움이 될 것 같아서 여기까지 적습니다😊

 

끝.