왜 필요할까?
많은 회사, 팀, 프로젝트에는 나름대로 정의한 고유한 코딩 스타일 가이드가 있고 해당 조직에 포함되어있다면 그 조직의 코딩 스타일을 지켜서 개발을 한다. 자유로운 영혼의 초보개발자가 코딩 스타일이라는 규칙을 부여받게 되면, 귀찮고 의미 없다고 느껴질 수 있지만 팀단위로 일하는것이 보편적인 개발업무에서 가독성 높은 코드는 굉장히 중요하다.
"Code is read much more often than it is written" -Guido Van Rossum
코드는 작성하는것보다 훨씬 더 자주 읽혀진다고 한다. 내가 작성한 간단한 함수를 다른 팀원이 읽고 이해해야될 수도 있고, 작성 후 1년이 지난 뒤 내가 작성한 그 코드를 내가 봐야할 수도 있다. 그 코드의 가독성에 따라 해당 코드를 읽는 사람의 읽고 이해하는데 걸리는 시간이 달라질 것이다.
코드의 양이 많아지고 로직이 복잡해질 수록 코드의 가독성은 매우 중요하기 때문에 파이썬에 어느정도 익숙해졌고 프로그래밍을 시작하는 단계라면 꼭 한번쯤은 코딩 스타일 가이드에 대해 공부하고 실무에 지속적으로 적용하면서 좋은 습관을 만들어 가는것이 좋다고 생각한다
명명 규칙
Python 코드를 작성할 때 변수,상수, 함수, 클래스, 모듈, 패키지 등 많은 이름을 지정해야 한다. 처음 이름을 대충 만들거나 일관성이 없게 만들면 나중에 코드를 읽기 어렵게 될 수 있기 때문에 변수명 만드는 것은 중요하고 생각보다 어렵다.
물론 변수명을 대충만든다 하더라도 당장 큰 문제가 발생하는것은 아니지만... 개발자는 대개 팀단위로 일을하고 자신이 지금 작성한 코드를 나중에 다시 보아야 할 일이 생기게 될것을 알고, 변수명이 혼란을 초래할수 있기때문에 이름짓기에 시간을 쓸수밖에 없다.
PEP-8에서는 아래와 같은 규칙으로 이름을 짓는것을 권장한다.
| Type | Naming Conventions | Examples |
|---|---|---|
| Function | Use a lowercase word or words. Separate words by underscores to improve readability. | function, my_function |
| Variable | Use a lowercase single letter, word, or words. Separate words with underscores to improve readability. | x, var, my_variable |
| Class | Start each word with a capital letter. Do not separate words with underscores. This style is called camel case or pascal case. | Model, MyClass |
| Method | Use a lowercase word or words. Separate words with underscores to improve readability. | class_method, method |
| Constant | Use an uppercase single letter, word, or words. Separate words with underscores to improve readability. | CONSTANT, MY_CONSTANT, MY_LONG_CONSTANT |
| Module | Use a short, lowercase word or words. Separate words with underscores to improve readability. | module.py, my_module.py |
| Package | Use a short, lowercase word or words. Do not separate words with underscores. | package, mypackage |
이 규칙을 따르더라도 "읽기 좋은 코드"를 작성하려면 문자와 단어선택에 주의해야 한다. 코드에서 올바른 이름 스타일 뿐만아니라, 단어 또한 신중하게 선택해야 한다.
- 변수명은 i, l, O 처럼 숫자와 햇갈릴수 있는 문자는 지양한다.
- 그런 문자가 아니더라도 x, y, z 등 수학적인 의미를 가진것이 아니라면, 해당 변수가 어떤 변수인지 알수있는 특정한 의미를 갖는 단어(명사)를 사용하도록 한다.
Ex) name, save_path, model_type - 함수, 메서드는 특정 행위를 수행하기 때문에 동사로 시작하는 이름을 짓는다.
Ex) get, change, save, send
코드 레이아웃
공백 라인
- 클래스와 함수(클로저 함수 제외)는 다른 문단과 구분하기 위하여 두줄의 공백으로 구분한다.
- 클래스 내부에서 정의하는 메서드는 서로 관련되어 있기때문에 공백 한 줄로 구분한다.
- 코드가 길어지는 경우 코드에서 일련의 절차를 구분하여 표시하기 위해 한줄의 공백으로 구분할 수 있다.
최대 줄 길이 및 줄바꿈
PEP 8에서는 코드 한줄에 문자를 79자로 제한해야 한다고 제안한다. 문장을 79자 이하로 유지하는 것이 항상 가능한 것은 아니기 때문에 명령문이 여러 줄에 걸쳐 실행되도록 하는 방법을 제시한다.
-
Library, module 등 Import시 백슬래시()로 줄을 바꾼다
- 여러개 Argument늘 갖는 함수를 정의할 때 argument 단위로 콤마(,)를 기준으로 줄을 바꾸어 정의한다
- 특정 수식 계산을 위해 코드가 길어진 경우, 연산자 입력 전에 라인을 바꿈으로써 어떤 변수가 어떤 연산이 수행되는지 즉시 확인할 수 있다
들여쓰기
파이썬 언어는 다른 언어와는 달리 조건문이나 반복문 등을 구분할때 bracket을 사용하지 않고 들여쓰기로 구분하기때문에, 매우 중요한 규칙이라고 볼 수 있다.
PEP 8에서는 4개의 연속된 공백을 사용하여 들여쓰기를 나타내며, 탭보다 공백을 선호한다.
코드 내에서 탭과 공백을 모두 사용하면 코드 실행이 불가능하기 때문에 하나만 잘 골라서 사용하도록 하자.
아마 VSCode에서 코드를 작성할때 tab키를 누르면 자동으로 공백으로 변환되서 입력되는 설정이 있는것같다...
주석
보기좋게 작성한 코드를 이해하기 쉽게 만들기 위하여 주석을 사용하여 작성된 코드를 문서화해야 한다. 아주 간단한 함수라면 코드 자체에서 의마를 전달할수 있도록 작성자면 되지만 특정 비즈니스 로직을 포함하거나 복잡한 계산이 필요하다면 주석으로 코드를 문서화하는것은 선택이 아닌 필수이다.
- DocString의 행 길이를 72자로 제한한다
- 대문자로 시작하는 완전한 문장을 사용한다
- 코드를 변경하는 경우 주석을 업데이트한다
인라인 주석
인라인 주석은 코드 조각의 단일 명령문을 설명하며, 특정 코드 줄이 필요한 이유를 상기시키거나 다른 사람에게 코드른 설명하는 데 유용하다.
하지만 인라인 주석은 쉽게 입력될 수 있고,특별한 이유가 없다면 사용하지 않고, 코드 자체를 주석이 필요없이 작성하는것이 좋다.
문서화 문자열 (DocString)
독스트링은 함수, 클래스, 메소드 또는 모듈의 첫 번째 라인에 나타나는 큰따옴표(""") 또는 작은따옴표(''')로 묶인 문자열이다. 이를 사용하여 코드를 설명하고 문서화할 수 있다.
DocString에도 여러가지 스타일이 있지만 스타일을 지키는것보다 코드 설명이 잘 되도록 작성하는것이 우선이다. DocString에 대한 내용은 별도로 작성해야겠다.
결론
PEP 8을 바탕으로 가독성 높은 Python 코드를 작성하는 방법에 대해 알아보았다. 나는 누군가가 정한 규칙을 따르는것을 좋아하는편이 아니고 귀찮아 하지만, 그 규칙이 일관성이 있고 통일성을 맞출수 있는 규칙이라면 기꺼이 따를수 있다. PEP 8 스타일가이드에 따라 코드를 작성하면 코드의 길이는 길어질 수 있지만 내가 작성한 코드의 질을 향상시키고 코드의 유지보수성을 향상시킬 수 있다.
