300x250

프로그래밍을 처음 접했을 때, 프로그래머들이 변수 이름, 파일 이름을 짓는 것에 가장 힘들어하고, 실제로 협업 시 각자 명명하는 방법이 다를 경우 헷갈려서 쓸데없는 시간을 낭비하는 결과를 초래한다는 얘기를 들어본 적이 있다.

파이썬에서는 이 문제를 해결하기 위해 PEP 8 - Style Guide for Python Code 라는 문서를 통해 명명법 이외에도 code lay-out 등 코딩을 할 때 애매한 것(문법이 틀리지는 않지만 정해지지 않은 것)에 대한 규칙을 정했다. 적용된 내용은 변경되지 않는다고 하니 숙지해두면 협업하는 데 도움이 될 것이다.

PEP8에서 다루는 내용 중 Naming을 위주로 다루고, 추가로 더 깔끔한 코딩을 위해 알아두면 좋은 규칙들을 자주 사용하는 것만 추려 간단히 정리해보려 한다.

 

 

목차

     

     

     

     

     

    Naming

     

    Naming은 함수, 변수 등에 이름을 붙일 때의 규칙이다.

     

     

     

    Naming Style

     

    먼저, 이름을 붙이는 style에 어떤 것들이 있는지 알아보자. (물론 모두 영어에 해당된다. 한글로 코딩하진 않으니까..)

    • single lowercase letter : 소문자 하나 ex) 'b'
    • single uppercase letter : 대문자 하나 ex) 'B'
    • lowercase : 모두 소문자로 쓰는 형태
    • lower_case_with_underscores : 소문자와 언더바(_)를 결합한 형태
    • UPPERCASE : 모두 대문자로 쓰는 형태
    • UPPER_CASE_WITH_UDERSCORES : 대문자와 언더바를 결합한 형태
    • CapitalizedWords (=CapWords, CamelCase, StudlyCaps) : 단어 별로 첫 글자를 대문자로 사용하는 형태 (단, 줄임말은 모두 대문자로 사용)
      • 예를 들어, HttpServerError보다는 HTTPServerError로 쓰는 것이 좋음
    • mixedCase : 위와 비슷하지만, 첫 글자는 소문자 (C 계열 언어에서 많이 사용되는 것으로 알고있다.)
    • Capitalized_Words_With_Underscores : 첫 글자 대문자 + 언더바 → 굳이 사용하지 않는다고 함

     

    언더바를 이름 맨 앞이나 맨 뒤에 사용하는 경우는 특별한 경우로, 꼭 지켜야 하는 경우도 있으니 알아두자. (완벽한 번역은 아니니까 이해만 해보자.)

    • _single_leading_underscore : 선행 언더바 (이름 앞에 언더바 하나가 오는 경우)
      • protected instance 속성이다. (모듈을 불러올 때 'from EX import *'로 모든 객체를 가져오는 경우, 이와 같이 명명한 객체는 가져오지 않는다.)
    • single_trailing_underscore_ : 후행 언더바 (이름 뒤에 언더바 하나가 오는 경우)
      • 변수 등이 파이썬 키워드와 충돌하지 않도록 하기 위해 위와 같이 명명한다.
    • __double_leading_underscore : 더블 선행 언더바 (이름 앞에 언더바 두 개가 오는 경우)
      • private instance 속성이다. 
    • __double_leading_and_trailing_underscore__ : 더블 선, 후행 언더바 (이름 앞, 뒤에 언더바 두 개씩 오는 경우)
      • magic 객체, 혹은 사용자 제어 namespace에 있는 속성을 나타낸다. 절대 이 형태의 변수 등을 만들지 말자. (문서에 적힌 대로만 사용하자.)
      • 예를 들어, 클래스를 만들 때 자주 사용하는 '__init__' 등이 있다.

     

     

     

     

    Naming

     

    이제 무엇을 나타내는가에 따라 이름을 붙이는 규칙을 알아보자.

    • 함수, 변수, 속성(클래스의 객체 내에서의 변수) : lower_case_with_underscore
    • 상수 : UPPER_CASE_WITH_UNDERSCORE
      • 특히 path같은 경우, 상수로 맨 위에 선언해 놓는 것이 코드 수정 및 보완 시에도 편하고, 가독성도 좋다.
    • 클래스, 예외 : CapWords
      • 예외는 클래스가 될 수 있다. 예외가 오류면 접미사로 'Error'를 사용한다.
    • 패키지, 모듈 : lowercase 혹은 가독성을 개선할 수 있을 경우 lower_case_with_underscore
      • 되도록 짧은 소문자로만 구성한다.

     

     

     

     

     

     

    Space, Blank Lines

     

    다음으로, 가독성을 높이기 위한 공백, 줄 띄우기 관련된 규칙을 알아보자. 개인적으로 가독성에 도움이 되고 자주 사용한다고 생각하는 부분은 빨간색으로 표시해 두었다.

     

     

    들여쓰기는 공백(space) 4번으로 정한다.

    한 줄의 문자 길이가 79자 이하여야 한다.

    여러 줄로 길게 표현되는 경우 괄호(())나 백슬래시(\)를 이용하여 여러 행으로 표현할 수 있다.

     

    가장 상위의 함수와 클래스 사이는 두 번 줄바꿈하여 구분하고, 클래스 안에서의 메서드는 한 번 줄바꿈하여 구분한다. (함수의 흐름을 나타낼 때 blank lline을 사용할 수 있으나, 적당히 사용하도록 한다.)

    class Flight:
    
        def __init__(self): # instance method → 첫 argument 항상 'self'
        # 생성자 아님에 유의. (실제 클래스 사용 시 'f = Flight()' 등과 같이 사용하는 것이 생성자.)
        # 객체에서 사용할 초기값들을 초기화
            print('init')
            super().__init__()
    
        def __new__(cls): # class method → 첫 argument 항상 'cls'
        # 생성자가 호출하는 함수로, 객체 생성 및 할당 (__init__ 메소드 호출해줌) → 실제로 필수로 선언하지는 않음
            print('new')
            return super().__new__(cls)
    
        def number(self): # instance method → 첫 argument 항상 'self'
            return 'SN060'

     

    Binary operator 앞, 뒤에 공백을 하나씩 사용한다. 우선 순위가 있을 경우 우선 순위가 가장 낮은 연산자 주위에 공백을 추가한다.

    # Correct
    x = 1
    # Wrong
    x=1
    
    # Correct
    x = x*2 - 1
    i = i + 1
    z = x*x + y*y
    c = (a+b) * (a-b)
    
    # Wrong
    x = x * 2 - 1
    i=i+1
    z = x * x + y * y
    c = (a + b) * (a - b)

     

    나도 항상 이항연산자 주위에 무조건 공백을 주었었는데, 앞으로는 우선순위를 고려해야 할 것 같다.

     

    Binary operator 전 후에 줄을 바꾸는 경우, 연산자가 줄바꿈 직후에 존재하도록 한다.

    # Correct
    income = (gross_wages
    		  + taxable_interest
              + (devidends - qulified_dividends)
              - ira_deduction)
    
    # Wrong
    income = (gross_wages +
    		  taxable_interest +
              (dividends - qualified_dividends) -
              ira_deduction)

     

     

     

     

     

    Comments

     

    Inline 주석(코드 오른쪽에 다는 주석)은 잘 달지 않는 경우가 많다. 해당 줄만 설명할 필요가 있는 경우, 두 칸 이상 충분히 띄운다.

     

    Block comments는 #를 사용하여 해당 block 바로 위에, documentation strings는 """ """로 묶어 표현한다. 긴 주석을 # 여러 줄로 작성하지 않는다. Docstring은 public module, function, class, method에 쓴다.

    # one-line docstring
    def kos_root():
        """Return the pathname of the KOS root directory."""
        global _kos_root
        if _kos_root: return _kos_root
        ...
    
    
    # multi-line docstring
    def complex(real=0.0, imag=0.0):
        """Form a complex number.
    
        Keyword arguments:
        real -- the real part (default 0.0)
        imag -- the imaginary part (default 0.0)
        """
        if imag == 0.0 and real == 0.0:
            return complex_zero
        ...

     

     

     

     

     

    Import

     

    파일의 맨 위에 import 문을 놓는다.

    모듈 import 시에는 항상 absolute import(절대 경로)로 진행한다. 부득이하게 relative import(현재 작업 location 기준 경로)를 해야한다면, 명시적으로 'from . import example'등과 같이 표시해준다. (점 하나 - current 경로, 점 두개 - parent 경로)

     

    Class를 포함하는 모듈을 import할 경우, 다음과 같이 import한다.

    from myclass import MyClass  # myclass : module, MyClass : class
    from foo.bar.yourclass import YourClass  # yourclass : module, YourClass : class
    
    # if spelling causes clashes,
    import myclass  # 모듈만 import. 사용 시 myclass.MyClass로 사용해야 함
    import foo.bar.yourclass  # 모듈만 import. 사용 시 foo.bar.yourclass.YourClass로 사용해야 함

     

    Module 종류에 따른 import 순서는 다음을 따르며, 각각의 사이에는 한 줄을 띄워준다.

    1. 표준 라이브러리(standard library) 모듈
      • os, shutil, sys, math 등, 다운받지 않아도 import 가능한 모듈
    2. 서드파티(third party) 모듈
      • numpy, pandas, matplotlib 등, pip나 conda로 다운받아서 사용하는 모듈
    3. 자신이 만든 모듈
      • 직접 코딩하여 '.py' 파일로 만들고, 다른 .py 파일에서 사용하는 모듈

     

     

    728x90
    • 네이버 블러그 공유하기
    • 네이버 밴드에 공유하기
    • 페이스북 공유하기
    • 카카오스토리 공유하기