Better Way 2
The Zen of Python
>>> import this
The Zen of Python, by Tim Peters
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!파이썬의 선, 팀 피터
아름다운 코드는 지저분한 코드보다 낫다.
명확한 코드는 암시적인 코드보다 낫다.
단순한 코드가 복잡한 코드보다 낫다.
복잡한 코드가 난해한 코드보다 낫다.
단조로운 코드가 복잡한 코드보다 낫다.
읽기 쉬운 코드는 읽기 어려운 코드보다 낫다.
가독성은 중요하다.
규칙을 깰 정도로 특별한 경우란 없다.
하지만 실용성은 이상을 능가한다.
에러를 결코 조용히 넘어가지 않도록 한다.
명시적으로 조용히 넘어가라고 하더라도 조용히 넘어가지 않는다.
모호한 코드를 대면할 때마다 추측하고 싶은 유혹을 거절하라.
문제를 해결할 단 하나의 명확하고 바람직한 방법이 있을 것이다.
하지만 처음에 코딩을 할 때는 잘 모를 수 있기에 코드의 동작 방법을 정확히 알지 못 할 수 있다.
아무 것도 안하는 것보다 지금 하는 게 낫다.
하지만 아무 것도 하지 않는 것이 지금 *당장* 하는 것보다 나을 수도 있다.
설명하기 어려운 구현이라면 좋은 아이디어는 아니다.
쉽게 설명할 수 있는 구현이라면 좋은 아이디어일 것이다.
네임스페이스는 매우 훌륭한 아이디어다. 많이 사용하자namespace란?
Python namespace에 대한 이해 / Python 네임스페이스
PEP8
PEP = Python Enhancement Proposals
PEP의 세가지 종류
- Standards Track PEP는 새로운 기능 혹은 구현을 설명하기 위한 PEP문서이다.
- Informational PEP는 Python의 설계 이슈 혹은 일반적인 가이드와 정보를 Python 커뮤니티에 전달하기 위해 작성하는 PEP문서이다.
- Process PEP는 Python과 관련된 프로세스를 기술하거나, 해당 프로세스에 대한 변경을 제안하는 PEP문서
PEP 8 -- Style Guide for Python Code
PEP8 한글 번역
Luavis' Dev Story - Python PEP 8
공백
- 탭 대신 스페이스 (4칸)
- 라인 길이는 79자 이하
- 줄을 넘길 때 적절히 들여쓰기
→ 다른 줄과 구분되도록 하는 것이 핵심
- 변수 대입 시 = 전후로 스페이스
- 키워드 인수 혹은 기본 매개변수 값을 나타내는 경우에는 = 기호 주위에 공백을 넣지 않는다
magic(r=real, i=imag) - 클래스의 메서드 정의는 한 줄을 띄워서 구분한다.
- 최상위 수준 함수와 클래스 정의는 두 줄을 띄워서 구분한다.
명명 규약
- 함수, 변수, 어트리뷰트는
snake_case표기법 - 클래스는
PascalCase표기법 - 보호해야하는 어트리뷰트는
_leading_underscore< 밑줄 1개 - 비공개 어트리뷰트는
__leading_underscore< 밑줄 2개 - 모듈 수준의 상수는 대문자.
MAX_OVERFLOW와TOTAL
식과 문
if not a is b→if a is not b/으로 줄을 나누기 보단, 괄호 안에서 줄바꿈을 한다- 배열 형태 타입은 비어있을 경우 False를 반환한다 →
if not 컨테이너를 활용하자
seq = []
# good
if not seq:
if seq:
# bad
if len(seq):
if not len(seq):- 짧은 if/for/while 구문을 한 줄에 넣는 것은 괜찮지만, 여러 절을 가진 구문은 절대 한 줄에 기술하지 않는다. 또한 한 줄에 여러 구문을 기술하면서 줄바꿈을 하는 것도 피해야 한다.
# good
if foo == 'blah':
do_blah_thing()
do_one()
do_two()
do_three()
# ok
if foo == 'blah': do_blah_thing()
for x in lst: total += x
while t < 10: t = delay()
# bad
if foo == 'blah': do_blah_thing()
else: do_non_blah_thing()
try: something()
finally: cleanup()
do_one(); do_two(); do_three(long, argument,
list, like, this)
if foo == 'blah': one(); two(); three()Import
- 한 줄에 하나의 모듈 임포트
- 임포트 순서는 (알파벳 순서로)
- 표준 라이브러리 모듈
- 3rd Party 모듈
- 직접 만든 모듈
- 절대 경로 권장
# bad
import mymodule
# good
import mypkg.mymodule
from mypkg.mymodule import *
from mypkg import mymodule
# 상대경로
from . import mymodule
from .mymodule import example
출처: https://codedragon.tistory.com/10309 [CodeDragon]그 외 인상 깊었던 부분
# 우선 순위가 낮은 연산자 주위에 공백을 주자
# bad
hypot2 = x * x + y * y
c = (a + b) * (a - b)
# good
hypot2 = x*x + y*y
c = (a+b) * (a-b)
# 예외를 처리할(catch)때에는 범용적인 except: 절 대신, 처리할 특정한 예외를 명시
try:
import platform_specific_module
except ImportError:
platform_specific_module = None
# try/except 절을 사용할 때에는 try 절이 적용되는 코드의 범위를 최소화
try:
value = collection[key]
except KeyError:
return key_not_found(key)
else:
return handle_value(value)
# string 모듈 대신 문자열 메서드를 사용한다
# 문자열 메서드는 항상 더 빠르며 유니코드 문자열과 동일한 API를 공유
if foo.startswith('bar'): # good
if foo[:3] == 'bar': # bad
# ==를 사용해서 True/False 값을 bool값과 비교하지 않는다
if greeting: # good
if greeting == True: # bad
if greeting is True: # worst코드 자동 포메팅도 있다!
autopep8, black, yapf, etc
