• Django Coding Style (장고 코딩 스타일)

    2021. 5. 11.

    by. Jacob Lee

    728x90

     


     

    Django Coding Style

     

    단순 명료하게 하라(Keep It Simple, Stupid)

    "단순함은 곧 고도의 정교 함이다"라는 말이 있다. 소프트웨어 프로젝트를 구축할 때 불필요한 부분들은 새로운 기능을 추가하거나 기존 기능들을 유지 보수하는 데 큰 방해가 된다. 단순함의 법칙을 적용하되 바보 같은 가정으로 너무 단순화된 구현은 하지 않도록 주의해야 한다. 이러한 개념은 종종 "KISS"라는 축약형으로 쓰이기도 한다.

     

    모델은 크게, 유틸리티는 모듈로, 뷰는 가볍게, 템플릿은 단순하게

    코드를 어디에 넣을지 결정할 때, 항상 "모델은 크게(Fat Models), 유틸리티는 모듈로(Utility Modules), 뷰는 가볍게(Thin Views), 템플릿은 단순하게(Stupid Template)"라는 규칙을 따라야 한다.

    뷰와 템플릿을 제외한 다른 부분에 더 많은 로직을 넣는 방법을 사용함으로써, 코드는 더 깔끔해지고, 문서화도 더 잘되며, 중복되는 부분은 줄어들고, 재사용 측면에서 훨씬 유용해진다. 탬플릿 태그와 필터는 가능한 최소의 로직을 포함해야 한다.

     

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

    코드는 한 번 작성하면 여러 번 읽힌다. 코드를 디버깅하거나, 자기가 썼던 코드를 오랜 시간이 지나고 다시 봐야 할 상황이 생기기 마련인데, 이럴 때 일관성 있는 코드를 사용한다 나중에 다시 보기도 편하며, 관리가 쉬워지고 프로젝트 개선 또한 수월해진다.

     

    즉, 코드를 최대한 읽기 쉽게 만들어야 하는데, 이를 위해서는 다음과 같은 노력이 수반되어야 한다.

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

    함축적이고 난해한 함수명은 꼭 피해야 한다. 예를 들면 balance_sheet_decrease처럼 그 의미가 설명이 되는 함수 이름을 bal_s_d와 같이 함축적이고 난해하게 쓰면 안 된다는 것이다. 아낀 몇 초가 큰 재앙을 일으킨다.

     

    PEP 8

    PEP8은 파이썬 공식 스타일 가이드다. 장고 역시 파이썬을 사용하기에 PEP8 관례가 중요한데, 다음과 같은 관례를 지켜주면 좋다.

    • 들여 쓰기에는 스페이스를 네 칸 이용한다.
    • 최상위 함수와 클래스 선언 사이를 구분 짓기 위해 두 줄을 띄운다.
    • 클래스 안에서 메서드들을 나누기 위해 한 줄을 띄운다.
    • 줄 바꿈을 해 들여 쓰기를 할 때는 수직으로 정렬하기보다는 네 칸을 띄어준다.
    # 좋은 예
    raise AttributeError(
        'Here is a multiline error message '
        'shortened for clarity.'
    )
    # 나쁜 예
    raise AttributeError('Here is a multiline error message '
                         'shortened for clarity.')
    • 이렇게 함으로써 첫 번째 라인이 바뀌어도 재 정렬할 필요가 없어진다.
    • 문자열에는 작은따옴표를 사용한다. 작은따옴표를 포함한 문자열일 때는 큰 따옴표를 사용한다.

     

    하지만 이미 PEP8이 아닌 다른 관례를 따르고 있는 프로젝트에 참여한다면, 기존 관례를 따르는 것이 좋다.

     

    79 칼럼의 제약

    PEP 8에서는 한 줄 당 텍스트를 79글자로 제한한다. 이렇게 함으로써 코드의 이해도를 떨어트리는 일을 피하기 때문이다. 오픈 소스 프로젝트에서는 꼭 지켜야 하지만, 프라이빗 프로젝트에서는 99 칼럼까지 늘리는 경우도 있다.

     

    Import(임포트)에 대해

    PEP 8은 임포트를 할 때 다음과 같은 순서로 그룹을 지을 것을 제안한다.

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

     

    장고 프로젝트에서 추천되는 임포트 순서는 다음과 같다.

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

     

    명시적 성격의 상대 임포트 사용하기

    코드를 작성할 때 코드들을 다른 곳으로 이동시키거나 이름을 변경하거나 버전을 나누는 등의 재구성을 손쉽게 할 수 있도록 구성하는 것은 매우 중요한 일이다. 파이썬에서는 명시적 성격의 상대 임포트(explicit relative import)를 통해 모듈의 패키지를 하드 코딩하거나 구조적으로 중속 된 모듈을 어렵게 분리해야 하는 경우들을 피해 갈 수 있다. 장고 또한 파이썬의 한 패키 지므로 이 혜택을 볼 수 있다.

     

    나쁜 예:

    from cones.models import WaffleCone 
    from cones.forms import WaffleConeFrom 
    from core.views import FoodMixin

    좋은 예:

    from .models import WaffleCone
    from .forms import WaffleConeFrom
    from .views import FoodMixin

    하드 코딩된 임포트 문을 사용한다면 앱의 이름을 바꾸어야 할 상황이 생겼을 때 큰 문제가 생긴다. 임포트 문은 일일이 바꾸어 줄 수 있겠지만 실제 프로젝트에선 추가적인 유틸리티 모듈까지 딸려올 수 있다.

     

    import *는 피해야 한다.

    from django.forms import *
    from django.db.models import *

    거의 모든 모듈은 개별적으로 임포트 해야 한다. 그 이유는 다른 파이썬 모듈의 이름 공간들이 현재 우리가 작업하는 모듈의 이름 공간에 추가로 로딩되거나 기존 것 위에 덮여 로딩되는 일을 막기 위해서다.

    또한 다음처럼 두 라이브러리가 CharField, 즉 동일한 이름의 두 라이브러리를 암묵적으로 로딩한다면 모델 라이브러리가 폼 버전의 클래스를 덮어쓰게 된다.

    from django.forms import CharField
    from django.db.models import CharField

     

    URL 패턴 이름에는 밑줄(_)을 이용한다

    대시(-) 대신 밑줄(_)을 이용하는 것이 좋다. 파이썬 다울뿐만 아니라 통합 개발 환경과 텍스트 편집기에 최적화된 스타일이기 때문이다.

    ### 나쁜 예
    url(... 
        name='add-topping')
    
    ### 좋은 예
    url(...
        name='add_topping')

     

     

    Reference

    728x90

    댓글