당신은 멋쟁이, 우리는 장고쟁이~

프로그래밍 권장사항들 - 3편

운영체체 에러를 잡아낼때에는,

파이썬 3.3 이후에서 소개된 명시적인 예외 상화관계를 사용합니다

모든 try/except구문

모든 try/except절에 대해 try 절을 필요한 최소의 코드 양으로 사용 제한을 합니다. 버그가 가려지는걸 피할수 있습니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

# 좋은예 
try:
    value = collection[key]
except KeyError:
    return key_not_found(key)
else:
    return handle_value(value)

# 나쁜예 
try:
    # 너무 광범위함 
    return
handle_value(collection[key])
except KeyError:
    # Will also catch KeyError raised by handle_value()
    return key_not_found(key)

특정 코드 섹션에 로컬 자원

자원이 특정 코드 섹션에 대해 로컬로 있을때에는 with문을 사용하여, 사용후 빠르고 안정적으로 정리되도록 합니다. try/finally 구문도 허용됩니다.

Context Manager

자원을 확보하거나 해제 하는것이 아닌 경우의 컨텍스트 메니져는 분리된 함수 혹은 메써드를 통해서 호출 되어야 합니다.

1
2
3
4
5
6
7

# 좋은예 
with conn.begin_transaction():
    do_stuff_in_transaction(conn)
    
# 나쁜예 
with conn:
    do_stuff_in_trnasaction(conn)

후의 예시는, __enter__ 및 __exit__ 메서드가 트랜셕션 후 연결을 닫는 것 이외의 작업을 수행하고 있음을 나타내는 정보를 제공하지 않습니다.

이 경우에는 명시적인게 중요합니다.

리턴 구문안에서는 일관성이 있어야 합니다

함수안에 모든 리턴 구문은 수식을 반환해야 합니다. 만약 어떤 리턴 구문이 수식을 반환할때. 어떠한 값이 없는 리턴 구문은 명시적으로, return None 이라고 해주어야 합니다.

그리고, 명시적인 리턴 구문은 함수의 마지막에 존재해야 합니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

# 좋은예 

def foo(x):
    if x >= 0:
        return math.sqrt(x)
    else:
        return None
    
def bar(x):
    if x < 0:
        return None 
    return math.sqrt(x)

# 나쁜예 

def foo(x):
    if x >= 0:
        return math.sqrt(x)
    
def bar(x):
    if x < 0:
        return 
    return math.sqrt(x)

문자열 모듈보다는 문자열 메써드 사용

문자열 메써드는 언제나 빠르고, 유니코드 문자와 함께 같은 API 를 공유합니다.

startswith() 와 endwith()

접두사와 접미사를 확인하기 위해서는, 문자열 슬라이싱 보다 startswith()와 endwith() 를 사용합니다.

startswith()와 endswith()가 더 깔끔하고 에러가 적습니다.

1
2
3
4
5

# 좋은예 
if foo.startswith('bar'):

# 나쁜예 
if foo[:3] == 'bar'

객체 타입 비교는 isinstance() 사용

객체 타입 비교를 할때는, 직접 타입 비교를 하기 보다는 isinstance()를 사용합니다.

1
2
3
4
5

# 좋은예 
if isinstance(obj, int);

# 나쁜예 
if type(obj) is type(1):

객체가 문자열인지 아닌지 확인할때에는, 그것이 유니코드 문자열일수도 있다는것을 염두해 두세요.

파이썬2 에서는, str과 unicode는 같은 베이스 클래스, basestring을 가지고 있습니다.

따라서, 아래와 같이 쓸수 있습니다.

1
2

# Python2 
if isinstance(obj, basestring)

파이썬3 에서는, unicode와 basestring은 존재하지 않습니다. str만 존재하고

bytes객체는 더이상 문자열 종류가 아닙니다.

시퀀스들(문자열, 리스트, 튜플) 빈 시퀀스는 False 를 반환합니다

1
2
3
4
5
6
7

# 좋은예 
if not seq:
if seq:
    
# 나쁜예 
if len(seq):
if not len(seq):

마치며..

프로그래밍 권장 사항들이 꽤 많네요.

나머지 권장 사항들은 다음 포스팅에 이어서 쓰겠습니다.

PEP8 프로그래밍 권장사항들 - 2편

BaseException이 아닌 Exception

BaseException 이 아닌

Exception 에서 예외를 파생 시킵니다.

BaseException에서 직접 상속은 예외를 잡는것이 틀린일인 예외를 위해 있습니다.

예외를 잡아내는 코드가 필요한 곳과, 예외가 발생하는곳을 잘 구분해서. 예외의 상하관계를 디자인 합니다.

“문제가 발생했습니다” 라는 단순한 얘기보다. 프로그래밍적으로 “무엇이 잘못됬지?” 라는 질문을 답하도록 목표합니다.

예외가 오류인 경우 예외 클래스에 접미사 Error를 추가해야 합니다만, 클래스 이름 지정 규칙이 여기에 적용됩니다.

PEP8 Programming Recommendations - 1편

프로그래밍 권장 사항들 - 1편입니다

다른 파이썬 라이브러리의 구현

코드는 다른 파이썬 구현에 불리하지 않은 방식으로 작성되어야 합니다.

다른 파이썬의 구현체들 (PyPy, Jython, IronPython, Cython, Pysco 등등)

예를들면, CPython에서 a += b 혹은 a = a + b 형태의 문자열 연결은 효율적인 구현체 이지만.

이 형태조차, CPython 에서도 특정 타입에만 통하고, 모든 구현에 나오지 않습니다.

따라서, CPython의 효율적인 내부 문자열 연결 구현에 너무 의존하는것은 좋지 않습니다

퍼포먼스가 중요한 라이브러리에서는, ''.join() 형태가 대신 사용되어야 합니다

파이썬 Naming Convention - 4편

Public and Internal Interface

이전 버전과 호환성을 보장하는것은

오직 퍼블릭 인터페이스에만 적용됩니다.

따라서, 사용자들은 퍼블릭 인터페이스와 내부 인터페이스를 잘 구분하는것이 중요합니다.

public interface (공용 인터페이스)는 독립적인 소프트웨어 엔티티가 상호 작용하는 논리적 지점입니다. 엔티니는 단일 컴퓨터, 네트워크 또는 다양한 토폴로지에서 서로 상호 작용할수 있습니다. 상호 작용을 계속 하려면, 퍼블릭 이너페이스가 안정적이여야 하고, 향후 변경 및 개선 및 사용중단을 지원하도록 잘 설계되어야 합니다.

파이썬 Naming Convention - 3 편

Presriptive: Naming Convention (Cont.)

지난 포스팅에 이어, Prescriptive Naming Convention 을 이어갑니다

Desigining for Interface

인터페이스를 위한 설계에 대한 내용입니다.

언제나

클래스의 메써드와 인스턴스 변수들이

퍼블릭값일지 아닐지에 대한 결정을 해야합니다.

결정하기가 쉽지 않다면, non-public 값을 선택 합니다.

나중에 non-public을 public으로 바꾸는게, public을 non-public으로 지정하는것보다 쉽습니다.

Public vs Non-Public Attributes

Public attributs (퍼블릭 속성)은 대외적으로 여러분들과 관계없는 클라이언트들이 클래스를 사용할것이 예상될때 사용합니다.

Non-ublic attributs (논 퍼블릭 속성)은 제 3자에 의해서 사용되지 않을때 사용하는 속성들입니다. non-public속성들은 나중에 수정되거나 삭제될수 있고. 수정이나 삭제에가 되지 않는다는 보장은 없습니다.

파이썬 Naming Convention - 2편

Prescriptive: Naming Conventions

타이틀이 prescriptive: Naming Conventions 인데. Prescriptive 의 뜻은 규범 혹은 처방등의 의미로 쓰입니다.

이름짓기에 관한 처방 혹은 규범이라는 뜻이 되겠네요.

Names to Avoid (피해야할 이름들)

절대로 피해야 할 변수명은, 아래와 같습니다.

• 소문자 엘l
• 대문자 오 O
• 대문자 아이 I

l (엘), O(오), I(아이)

이 문자들은, 숫자 1과 0 하고 구분이 잘 안가기 때문에 사용하는것을 피해야 합니다.

ASCII 호환

파이썬 스탠다드 라이브러리에서 사용되는 식별자들은 ASCII 호환이 되어야 합니다.

이 부분은, PEP3131에 나와있습니다.

파이썬 Naming Convention

파이썬에서의 이름짓기 규칙은 조금 지저분합니다. 따라서, 우리는 이름짓기를 완벽하게 일반화하여 일관성있게 할수가 없습니다.

그렇지만, PEP8 에서는 현재 권장되는 이름짓기 규칙과 naming standard 를 제시합니다

새로운 모듈과 패키지들은

PEP8에 나와있는 naming convention 대로 이름이 지어져야 합니다.

하지만

존재하고 있는 라이브러리들은 이미 다른 스타일들을 가지고 있기 때문에,

내부적으로 일관성을 정하여 이름을 사용합니다.

Comments (주석)

파이썬에서 주석에 관한 스타일 가이드 입니다.

코드와 모순된 주석은

주석이 없는것보다 나쁩니다

코드와 모순된 주석을 달바에는 아예 달지 않는게 낫다는 얘기지요 ㅎㅎ

주석이 코드와 모순되지 않게 하기 위해서,
코드가 바뀔때 주석도 같이 수정사항에 맞게 업데이트 해줘야 합니다.

주석에 쓰이는 문장은 완성된 문장이여야 하고, 소문자로 시작하는 식별자들을 제외하곤 첫번째 단어는 대문자로 써줍니다.

언제 콤마를 뒤에 붙여야 하는가

이번 포스팅은 언제 코드끝에 콤마를 붙여야 하는가에 대한 내용입니다.

튜플처럼 의무화 되어 있는 콤마를 제외하고는

보통은 끝에 콤마를 붙이는것은 선택 사항입니다.

1
2
3
4
5
6

# 좋은예 
FILES = ('setup.cfg',)

# 나쁜예 
# 괄호가 없는데 뒤에 콤마를 붙이는 경우 
FILES = 'setup.cfg',

콤마는 버전관리 시스템이 사용될때도 도움이 됩니다.

그리고, 값들이 리스트 안에 들어가 있는데, 그 안에 인자나 가져올 아이템이 나중에 확장될지 모를때 도움이 됩니다.

코드를 보면서 이해하자면

수식과 구문안에서 빈공간 - 기타 권장 사항들

수식과 구문 안에 공백들에 대한 기타 권장 사항들입니다.

뒤에오는 빈공간은 언제나 피해야 합니다

공백들은 보이지 않기 때문에 혼란 스러울수 있습니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

# 빈공간 후에 \ 를 사용 

print("I'm the best"  \)
print("I'm the best
      \")
      
# 빈공간이 계속되는 줄로 세어지지 않을때, 
# 아래 print 문에서 두번째줄은 계속되는 줄로 세어지지 않습니다. 
# 이어지는 줄이 아닌데도 괜히 사용하면, 시각적으로나 논리적으로 혼란만 초래합니다. 
      
print("I'm the best"
     
     
)

Binary Operator 양쪽 사이드

이항 연산자 양쪽 사이드에는 항상 하나의 공백을 넣어줍니다.