수식과 구문안에서 빈공간

이번토픽은 PEP8에서 다루는 공백에 대한 포스트입니다.

포스팅을 시작하기 전에, 프로그래밍언어 안에서 쓰이는 expressions 이라는 단어와 Statements에 대한 뜻을 먼저 알고 시작하겠습니다.

Expressions 와 Statements

영어에서는 expressions은 표현, statements는 진술서 라는 의미로 쓰이는게 많은데.

프로그래밍 세계에서 의미하는 바는 조금 다른것 같아. 아래와 같이 요약합니다.

Expressions

수식, 연산식

예) 1 + 1 = 0 혹은 a = 3

Statements

실행 가능한 (executable) 코드 조각.

보통 여러개의 expressions 로 이루어져 있습니다.

1
2
3
4
5
6
7

# 함수안에 실행 가능한 구문이 Statements 입니다. 
# 여러개의 Expressions 로 이루어져 있는걸 확인 할수 있습니다. 

def addition():
    a = 1 
    b = 2 
    return a + b

String Quotes (문자열 따옴표)

파이썬에서는,

문자열을 사용할때 작은따옴표와 큰따옴표는 똑같습니다.

PEP8 에서는, 따옴표의 사용에 대한 어떠한 권장 사항이 없습니다.

단지 하나의 룰을 정하고, 그것을 일관되게 사용하길 바랍니다.

1
2
3
4

string = "This is string" 	# 큰 따옴표를 사용한 경우 
string = 'This is string'	# 작은 따옴표를 사용한 경우 

# 두가지 방식은 같음

마치며..

저는 보통 작은 따옴표 '를 사용합니다.. shift키를 안눌러도 되서 그런가 봅니다.

여러분들은 어떠신가요?

Module 내에 Dunder Names

모듈 레벨에서 Dunder Names

모듈 레벨에서 __all__, __author__, __version__ 같은 “dunders” 는 모듈 docstring 뒤에 그리고 __future__를 제외한 모든 import 구문 앞에 붙입니다.

dunders

언더스코어 _ 두개가 붙는 메소드로

Double UNDERscore Method 를 줄여서

Dunder 메소드라고 부릅니다.

PEP8 Code Layout - Imports (가져오기)

PEP8 코드 레이아웃, imports편 입니다.

imports 는 해당 파일에 다른 함수나 모듈을 불러올때 사용하는 명령어 입니다.

표준 라이브러리 기능이나, 다른 모듈에 있는 함수, 클래스 혹은 메써드들을 가져올때 사용합니다.

PEP8에 따르면, Imports 는 보통 별도의 줄로 되어 있어야 합니다.

1
2
3
4
5
6

# 좋은예 
import os 
import sys 

# 나쁜예 
import sys, os

하지만, 아래의 경우도 괜찮습니다.

1
2

# 좋은예
from subprocess import Popen, PIPE

Source File Encoding (소스파일 인코딩)

이번 토픽은 소스파일 인코딩 입니다.

파이썬 배포에 사용되는 코드는 항상 UTF-8 을 사용해야 합니다.

파이썬2 에서는 ASCII

https://namu.wiki/w/UTF-8

UTF-8 은 가장 많이 사용되는 가변길이 유니코드 인코딩이다.

GO 언어를 만든 켄 톰슨과 롭 파이크가 만들었다

[https://namu.wiki/w/%EC%95%84%EC%8A%A4%ED%82%A4%20%EC%BD%94%EB%93%9C?from=ASCII](https://namu.wiki/w/아스키 코드?from=ASCII)

ASCII 코드는 미국 ANSI 에서 표준화한 정보 교환용 7비트 부호체계

2 바이트 이상의 코드를 표현할수 없기 때문에.

국제 표준에서는 유니코드로 넘어감.

PEP8에 따르면, 파이썬2에서 ASCII 를 사용하는 파일들이나 혹은 파이썬3에서 UTF-8을 사용하는 파일들 모두

인코딩 선언이 되어 있지 않아야 합니다.

PEP8 Code Layout - Blank Lines (빈줄)

이번 토픽은, PEP8 에서 권장하는 코드내에 빈줄 공간들에 대해서 다룹니다.

가장 상위의 함수와 클래스 정의는 2줄의 빈줄로 공간을 둡니다

이것이 의미하는 바는 아래의 예제를 보면 알수 있습니다.

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

# 가장 상위의 함수와 클래스들 사이의 2줄 공간 
# 가장 상위의 클래스 두개끼리는 2줄의 빈공간이 있습니다. 

class DjangoJenge():
    pass 


class DjangoJenge2():
    pass 


# 가장 상위의 함수 두개끼리는 2줄의 빈공간을 둡니다. 

def Djangojeng():
    pass 


def Djangojeng():
    pass

클래스 내의 메써드 정의는 1줄로 공간을 둡니다.

이항연산자 전후 줄바꿈

이항 연산자 전에 줄바꿈을 해야할까요 아니면 후에 줄바꿈을 해줘야 할까요?

줄바꿈은 연산기호 전에 되어야 하는가?

아니면

줄바꿈은 연산기호 후에 되어야 하는가?

몇십년동안, 줄바꿈은 연산기호 후에 해주는것이 권장 되어 왔습니다.

하지만, 줄바꿈을 연산기호 후에 해주면, 두가지 이유로 가독성을 떨어트립니다.

1) 연산기호들이 스크린에 세로줄로 흐트러지고, 이전줄에 있는 피연산자들(opernand) 과 떨어지게 됩니다.

2) 시각적으로 어떤것들이 더해지고, 빼줘야 하는것인지 파악하는데에 시간을 들여야 합니다.

연산기호들이 피연산자들과 멀리 떨어져 있는 경우의 예를 들어봅니다

1
2
3
4
5
6
7
8
9
10

# 연산기호들이 이전줄의 피연산자들과 떨어져 있는 경우의 코드 

income = (gross_wages +
         taxable_interest +
         (dividends - qualified_dividends) -
         ira_deduction - 
         student_loan_interest)

# 줄바꿈이 연산기호인 + 혹은 - 이후에 이루어진것을 확인 할수 있습니다. 
# 코드를 읽어가면서 어떤것을 더해주고 빼주어야 하는지 눈으로 더 확인 해봐야 하는 상황이 옵니다.

위 상황에서 가독성이 떨어지기 때문에, 수학자들과 퍼블리셔들은 반대의 관례를 따르기 시작합니다.

문단안에 있는 공식들은

언제나 연산기호 뒤에 줄바꿈을 하지만

잘 진열된 공식들은 언제나 연산기호 전에 줄바꿈을 합니다

Donald Knuth in “Computers and Typesetting series”

수학적 전통을 따르면, 결과적으로 더 읽기 편한 코드가 나옵니다. 아래 예시 코드를 참조합니다.

1
2
3
4
5
6
7
8
9

# 코드에서 줄바꿈을 연산기호 전에 하면
# 연산기호들과 피연산자들을 매칭 시키기 쉬운 코드가 됩니다. 
# PEP8 에서 나온 좋은 예시는 아래와 같습니다. 

income = (gross_wages
         + taxable_interest
         + (dividends - qualified_dividens)
         - ira_deduction
         - student_loan_interest)

마치며..

파이썬 코드에서는, 줄바꿈을 연산기호 전이나 연산기호 후에 하는 두가지 방법이 모두 허용됩니다.

어떤 방법이던, 해당 지역의 관례와 맞는다면, 두가지 방식은 다 괜찮습니다.

저는 개인적으로, 연산기호 전에 줄바꿈을 해주는것이 가독성에 좋다고 생각합니다.

Maximum Line Length

Maximum Line Length 는 한줄의 최대 길이를 의미 합니다.

모든 줄은 79자로 제한 합니다

네. PEP8 에서는, 파이썬 코드를 작성할때. 한줄의 최대 길이를 79자로 제한합니다.

다만! docstring혹은 comments 즉 주석들은, 72자로 제한합니다.

모든 팀원들이 동의한다는 전제하에,

특별히 코드의 긴 줄이 유지 되어야 하는 상황이거나 하면

최대 길이는 99자까지 늘릴수 있습니다.

한줄이 너무 긴 코드 줄 바꾸기

PEP8 에서 선호하는 긴줄 처리는,

계속되는 줄의 경계를 소괄호, 중괄호, 대괄호 안에 넣고 사용하는것입니다.

이 방법이 \ 를 사용하는 방법보다 선호됩니다.

제가 생각하는 예시들은 아래와 같습니다.

1
2
3
4
5
6
7
8
9
10

# 한줄이 너무 긴 코드 
if(this_is_one_thing or that_is_another_thing or everything_is_good_thing or you_are_the best):
    
# \ 백슬레쉬를 사용하지 않고, 괄호안에서 줄을 바꿔서, 한줄을 다음줄로 나눕니다. 
# 물론 들여쓰기는 잘해주어야 하겠죠? 

if(this_is_one_thing or
   that-is_another_thing or
   everything_is_good_thing or
   you_are_the_best):

위 방법이 선호되는것 같으나, 여전히 \백슬레쉬의 사용하는 방법도 괜찮습니다!

1
2
3
4
5

# \ 를 사용하여 줄을 나눈 경우, \를 사용하지 않았으면, 한줄이 너무 길어 졌을것 같습니다. 
with open('/path/to/some/file/you/want/to/read') as file_1, \
     open('/path/to/some/file/being/written', 'w') as file_2:)
     file_2.write(file_1.read())

마치며..

1) PEP8 에서는 한줄의 최대길이를 79자로 제한합니다.

2) docstring 이나 comments 같은 주석들은 72자로 제한합니다.

3) 한줄이 너무 길어질것 같으면, \나 괄호안의 문장을 다음줄로 이어갑니다 (들여쓰기는 적절히 해야하는게 필수)

한줄 한줄이 너무 길어서 스크린이 꽉꽉 차있으면, 일하러 가서 매일 아래와 같은 스크린을 보게 될것입니다.

그리고, 누가 그러시던데, 한줄의 길이가 79자가 된 이유중에 하나가.

옛날 컴퓨터의 모니터 크기 때문이라고 합니다. 지금 나오는 모니터 크기와는 다르게.

옛날 모니터들은 가로폭이 굉장히 좁아서. 화면에 꽉차는 양이 79자 정도 였다 합니다.

아래 사진을 보면,,, 충분히 그럴수도 있었겟네요? ㅎㅎ

PEP8 Code Layout - Tab 혹은 Spaces?

파이썬에서는 Tab 대신 Spaces(빈공간)을 사용하는것을 선호합니다.

탭을 사용하는 경우는, 이미 코드가 tab으로 들여쓰기가 되어 있는 경우,

코드와 일관되게 tab을 사용합니다.

Python3 에는 tab과 spaces 혼용 사용을 허락하지 않습니다.

tab과 spaces의 혼용으로 들여쓰기가 되어진 Python2 버전의 코드는 특별히 spaces를 사용해서 전환되어야 합니다.

Python2 커맨드 라인 인터프리터로 -t옵션을 사용하면,

tabs와 spaces의 혼용된 코드에 대해서 경고를 줍니다.

--t옵션을 사용하면, 이 경고들이 에러가 됩니다.

PEP8 Code Layout - Indentation (들여쓰기)

Indentation

파이썬에서, 들여쓰기는 문법으로 의무화 되어 있습니다.

PEP8에서는 들여쓰기에 대한 코딩 스타일을 다루고 있습니다.

들여쓰기는 4칸을 사용합니다.

Continuation lines, 즉 이어지는 줄들은 세로로 정렬이 되어야 하는데.

1) 파이썬에서 암시적으로 이어지는 줄들을 소괄호, 중괄호, 대괄호 안에 묶거나,

2) hanging indent 를 사용하여 정렬합니다.

hanging indent 를 직역하면, 매달려 있는 들여쓰기로.

문단의 첫번째 줄을 제외한 모든 라인이 들여쓰기가 되어 있는 스타일 입니다.

hanging indent 의 예를 들어봅니다