[Two Scoops of Django] 1장. Coding Style

guava·2021년 8월 30일

Two Scoops of Django django

Two Scoops of Django

목록 보기

1/12

Two Scoops of Django 3.x를 읽고 정리한 글입니다

1.1. 읽기 쉬운 코드를 만드는것이 왜 중요한가?

코드의 가독성이 좋고 이해하기 쉬우면 프로젝트 규모에 상관없이 유지 관리사 쉬워지며, 개선작업이 수월해진다.
코드는 쉽게 만들어야 하며, 이를 위해서는 노력이 필요하다.

축약적이거나 함축적인 변수명은 피한다.
- bal_s_d → balance_sheet_decrease
함수 인자의 이름들은 꼭 써준다.
클래스와 메서드를 문서화 한다.
코드에 주석은 꼭 달도록 한다.
재사용 가능한 한수 또는 메서드 안에서 반복되는 코드들은 리팩터링을 해준다.
함수와 메서드는 가능한 한 작은 크기를 유지한다. 어림잡아 스크롤 없이 읽을 수 있는 길이가 적합하다.

⇒ 궁극적인 목적은 잊고 지내다가도 다시 보았을 때 빠르게 이해하기 위함이다.

1.2. PEP 8

PEP 8은 파이썬 공식 스타일 가이드다. 장고 프로젝트에서는 이 관례를 따르도록 하자. (가독성과 일관성?)

1.2.1. 79칼럼의 제약 (link)

79자를 넘어서면 줄바꿈을 지원하는 텍스트 편집기 등에서 가독성을 떨어 뜨린다.

오픈 소스 프로젝트에서는 79칼럼 제약을 반드시 지킨다. → 프로젝트의 기여자 혹은 방문자들은 끊임없이 이에대해 지적할 것이다.
프라이빗 프로젝트에 대해서는 99칼럼까지 제약을 확장하는것도 좋다.

"농담이 아니라 정말로 난 여전히 화면에 80칼럼 제약이 있는 콘솔에서 작업을 한다."
베리 모리슨 (이 책의 리뷰어)

"79칼럼을 맞추려고 변수나 함수 이름 또는 클래스 이름을 줄여서 짓는 것은 허용될 수 없다. 수십년전 하드웨어 기준으로 만들어진 말도 안 되는 숫자를 지키기 보다는 읽기 쉽고 의미 있는 변수명을 만드는 것이 더욱 중요한 일이다."

애머릭 어거스틴

1.3. 임포트에 대해

PEP 8에서의 임포트 방법

표준 라이브러리 임포트
연관 외부 라이브러리 임포트
로컬 애플리케이션 또는 라이브러리에 한정된 임포트

장고 프로젝트에서 임포트 순서

표준 라이브러리 임포트
코어 장고 임포트
장고와 무관한 외부 앱 임포트
프로젝트 앱 임포트

# 표준 라이브러리 임포트
from math import sqrt
from os.path import abspath

# 코어 장고 임포트
from django.db import models
from django.utils.tranlation import ugettext_lazy as _

# 서드파티 앱 임포트
from django_extensions.db.models import TimeStampedModel

# 프로젝트 앱 임포트
from splits.modes import BananaSplit

1.4. 명시적 성격의 상대 임포트 이용하기

코드를 작성할 때 코드들을 다른 곳으로 이동시키거나 이름을 변경하거나 버전을 나누는 등의 재구성을 손쉽게 할 수 있도록 구성하는 것은 매우 중요하다.

다음은 하드 코딩된 임포트 문을 포함하고 있다. (권장되지 않는다.)

# cones/views.py
from django.views.geneeric import CreateView

# 'cones' 패키지에 하드코딩 된 암묵적 상대 임포트가 이용되었다. (따라하지 말기)
from cones.models import WaffleCone
from cones.forms import WaffleConeForm

# 'core' 패키지에서 절대 임포트
from core.views import FoodMixin

class WaffleConeCreateView(FoodMixin, CreateView):
    model = WaffleCone
    form_class = WaffleConeForm

위의 예제는 이식성 또는 재사용성에서 문제가 있다.

새로운 앱에서 'cone'앱을 재사용하려고 한다면? 이 때 이름이 같은 앱이 이미 존재한다면 엉뚱한 cone패키지를 임포트할 수도 있다.

하드코딩된 임포트 구문을 포함하고 있는 안좋은 예제를 다음과 같이 명시적 상대 임포트 예제로 바꿔보자.

# cones/views.py
from django.views.generic import CreateView

# 'cones' 패키지 명시적 상대 임포트
from .models import WaffleCone
from .forms import WaffleConeForm

# 'core' 패키지에서 절대 임포트
from core.views import FoodMixin

class WaffleConeCreateView(FoodMixin, CreateView):
    model = WaffleCone
    form_class = WaffleConeForm

코드	임포트 타입	용도
`from core.views import FoodMixin`	절대 임포트	외부에서 임포트해서 현재 앱에서 이용할 때
`from .models import WaffleCone`	명시적 상대	다른 모듈에서 임포트해서 현재 앱에서 이용할 때
`from core.views import FoodMixin`	암묵적 상대	명시적 상대와 같은 용도로 쓰지만 좋은 방법은 아니다

표1.1 임포트: 절대 vs 명시적 상대

1.5. import *는 피하자.

from django import forms
from django.db import models

# 안티 패턴
from django.forms import *
from django.db.models import *

예제 1.3과 달리 나쁜 예제 1.2는 작업 모듈의 이름 공간에 추가로 로딩이 되어 문제가 발생할 수 있다.
예를 들면 django.forms와 django.db.models는 둘다 CharField를 가지고 있기 때문에 암묵적 로딩에 의해 django.db.models의 모듈이 전부 덮어써버린다.

1.6. 장고 코딩 스타일

1.6.1. 장고 코딩 스타일

장고는 내부적으로 PEP8을 확장한 스타일 가이드라인을 가지고 있다. (link)

1.6.2. URL 패턴 이름에는 대시(-)대신 밑줄(_)을 이용한다

파이써닉한 스타일
통합 개발 환경과 텍스트 편집기에 최적화 된 스타일
여기서 말하는 URL은 실제 URL주소가 아닌 path()에 인자로 쓰이는 name 이다.

patterns = [
    path(route='add/',
        view=views.add_topping,
        name='add-topping'),
]

patterns = [
    path(route='add/',
        view=views.add_topping,
        name='topping:add_topping'),
]

실제 URL주소에서 대시를 쓰는데에는 문제가 없다. (e.g. route=’add-topping/’ )

1.6.3. 템플릿 블록 이름에 대시 대신 밑줄을 이용한다

템플릿 블록을 정의하는 이름도 밑줄을 쓰도록 한다.

1.9. 요약

위의 코딩스타일이 아니더라도 일관된 코딩 스타일을 정한 후 일관성 있게 따르는 것이 중요하다.
여러 스타일이 섞여 있는 프로젝트는 실수를 유발하고, 개발을 더디게 하며, 유지보수에 애를 먹게된다.

guava

다음 포스트

[Two Scoops of Django] 1장. Coding Style