분류 |
구분 |
원문 발취 |
요약 |
Code Lay-out |
Indentation |
Use 4 spaces per indentation level. |
들여쓰기 1개당 4개의 공간을 사용하자. |
Tabs or Spaces |
|
|
Maximum Line Length |
Limit all lines to a maximum of 79 characters (and docstrings/comments to 72).
to using a backslash for line continuation. |
79개의 문자 길이 제한하자.
코멘트의 경우 72개로 제한하자. |
Blank Lines |
Surround top-level function and class definitions with two blank lines.
Method definitions inside a class are surrounded by a single blank line.
Use blank lines in functions, sparingly, to indicate logical sections. |
최상의 함수나 클래스 : 2 줄
클래스 내부 매소드 : 1 줄
함수 내부 로직 섹션 : 1 줄 |
Source File Encoding |
Code in the core Python distribution should always use UTF-8 (or ASCII in Python 2).
Files using ASCII (in Python 2) or UTF-8 (in Python 3) should not have an encoding declaration.
All identifiers in the Python standard library MUST use ASCII-only identifiers |
기본 인코딩
- Python3 : UTF-8
- Python2: ASCII
식별자들은 ASCII를 사용해야만 한다. |
Imports |
Imports should usually be on separate lines.
Imports are always put at the top of the file, just after any module comments and docstrings, and before module globals and constants.
Wildcard imports ( from <module> import * ) should be avoided |
라이브러리 단위로 구분 선언하자.
임포트는 파일의 상단에 선언하자.
- 문서 요약(docstring)
- 임포트
- 전역 변수 선언
임포트 순서 (1 줄 띄우기)
- 표준 라이브러리
- 관계(3rd) 라이브러리
- 로컬 명세 라이브리리
와일드카드(*) 사용을 피한다. |
String Quotes |
use the other one to avoid backslashes in the string.
For triple-quoted strings, always use double quote characters |
싱글(‘), 더블(“) 병행 사용은 ‘\’ 사용을 피할 수 있다.
문서 요약을 위한 트리플(“””)은 더블(“) 만 사용하자. |
Whitespace in Expressions and Statements |
Pet Peeve |
Immediately inside parentheses, brackets or braces.
Immediately before a comma, semicolon, or colon:
Immediately before the open parenthesis that starts the argument list of a function call:
Immediately before the open parenthesis that starts an indexing or slicing:
More than one space around an assignment (or other) operator to align it with another. |
공백을 사용하지 않는 유형
- 괄호 바로 안쪽
- 콤마/세미콜론/콜론 전
- 리스트,함수 괄호 시작 전
- 인덱싱,슬라이싱 시작 전 |
Other Recommendations |
Compound statements (multiple statements on the same line) are generally discouraged.
put an if/for/while with a small body on the same line, never do this for multi-clause statements. |
문장/구문은 대략 한 라인에 표현하지 말자. |
Comments |
Block Comments |
Block comments generally apply to some (or all) code that follows them, and are indented to the same level as that code. |
코드와 같은 레벨에 처음에 ‘#’ 주석한다. |
Inline Comments |
An inline comment is a comment on the same line as a statement. |
간랸한 내용은 같은 라인에 ‘#' 주석한다. |
Documentation String |
Write docstrings for all public modules, functions, classes, and methods. Docstrings are not necessary for non-public methods, but you should have a comment that describes what the method does. This comment should appear after the def line.
the """ that ends a multiline docstring should be on a line by itself. |
모듈, 함수, 클래스, 매소드의 바로 뒤에 트리플(“””) 블럭을 사용해서 문서화 하자.
마침 트리플(“””)은 같은 레벨에 쓰자.
—— 예제 ——
“”” 제목
본문
“”” |
Version Bookkeeping |
|
|
|
Naming Conventions |
Overriding Principle |
Names that are visible to the user as public parts of the API should follow conventions that reflect usage rather than implementation. |
관습적인(익숙한) 이름을 사용하자. |
Descriptive: Naming Styles |
Capitalized_Words_With_Underscores (ugly!)
_single_leading_underscore : weak "internal use" indicator. E.g. from M import * does not import objects whose name starts with an underscore.
single_trailing_underscore_ : used by convention to avoid conflicts with Python keyword,
__double_leading_underscore : when naming a class attribute, invokes name mangling (inside class FooBar, __boo becomes _FooBar__boo ; see below).
double_lading_and_trailing_underscore : Never invent such names; only use them as documented. |
대문자화 문자는 Http에서 문제가 될 수 있자.
대문자화 문자와 밑줄을 섞는 건 최악이다.
_single_leading_underscore
: 내부적인 이름으로 사용하자.
single_traing_underscore_
: 예약어와 겹칠 때, 사용하자.
__double_leading_underscore
: 클래스 속성 일때 _클래스__이름 형태로 변환됨
__double_leading_and_trailing_underscore__
: 문서 가이드에 따라 사용하자. |
Prescriptive: Naming Conventions |
Names to Avoid
Never use the characters 'l' (lowercase letter el), 'O' (uppercase letter oh), or 'I' (uppercase letter eye) as single character variable names. |
l, O, I를 단문자 변수 이름으로 사용하지 말자.
|
Package and Module Names
Modules should have short, all-lowercase names. Underscores can be used in the module name if it improves readability. Python packages should also have short, all-lowercase names, although the use of underscores is discouraged. |
모듈이름은 밑줄을 사용할 수 있고, 짧은 소문자를 사용하자.
패키지 이름은 짧은 소문자를 사용하자. |
Class names
Class names should normally use the CapWords convention. |
클래스 이름은 CapWords를 사용하자.
|
Exception Names
Because exceptions should be classes, the class naming convention applies here. However, you should use the suffix "Error" on your exception names (if the exception actually is an error). |
예외 이름은 클래스 이름 형식에 접미사를 붙이자. |
Global Variable Names
The conventions are about the same as those for functions. |
전역 변수는 대략 함수와 같다. |
Function Names
Function names should be lowercase, with words separated by underscores as necessary to improve readability. |
함수 이름은 밑줄로 구분된 소문자를 사용하자. |
Function and method arguments
it is generally better to append a single trailing underscore rather than use an abbreviation or spelling corruption. |
함수의 입력변수 이름이 겹치면 후미에 밑줄을 붙이자. |
Method Names and Instance Variables
Use the function naming rules: lowercase with words separated by underscores as necessary to improve readability.
Use one leading underscore only for non-public methods and instance variables.
To avoid name clashes with subclasses, use two leading underscores to invoke Python's name mangling rules. |
메소드나 변수는 밑줄로 구분된 소문자를 사용하자.
비공개 메소드나 변수는 앞에 밑줄을 사용하자.
서브클래스는 앞에 두개의 밑줄을 사용하자. |
Constants
Constants are usually defined on a module level and written in all capital letters with underscores separating words. |
상수는 밑줄로 구분된 대문자를 사용하자. |
Programming Recommendations |
|
|
|