• 코딩 스타일

  • Coding style

  • 코딩 스타일

  • Please follow these coding standards when writing code for inclusion in Django.
  • Django에서 코드를 작성할 때는 아래의 코딩 표준을 따라 주세요.
  • Python style

  • 파이썬 스타일

  • - Please conform to the indentation style dictated in the .editorconfig file. We recommend using a text editor with EditorConfigsupport to avoid indentation and whitespace issues. The Python files use 4 spaces for indentation and the HTML files use 2 spaces.
  • - .editorconfig 파일에 정의한 들여쓰기 스타일을 따라주세요. 들여쓰기와 공백 문제를 피하기 위해 EditorConfig를 지원하는 텍스트 에디터 사용을 권장합니다. Python 파일은 스페이스 4개, HTML 파일은 스페이스 2개를 들여쓰기로 사용합니다.
  • - Unless otherwise specified, follow PEP 8.
  • - 다른 특별한 사유가 없다면, PEP 8을 따르세요.
  • Use flake8 to check for problems in this area. Note that our setup.cfg file contains some excluded files (deprecated modules we don’t care about cleaning up and some third-party code that Django vendors) as well as some excluded errors that we don’t consider as gross violations. Remember that PEP 8 is only a guide, so respect the style of the surrounding code as a primary goal.
  • 이 영역 내 문제를 확인하기 위해 flake8을 사용하세요. 우리의 setup.cfg 파일은 우리가 중대한 위반이라고 생각하지 않은 삭제된 파일(우리가 정리하지 않은 사용이 중지된 모듈과 장고 개발자사의 써드파티 코드) 뿐만 아니라 에러들을 포함합니다. PEP 8은 단지 가이드임을 명심하세요. 먼저 주변의 코드 스타일을 존중하기를 바랍니다.
  • An exception to PEP 8 is our rules on line lengths. Don’t limit lines of code to 79 characters if it means the code looks significantly uglier or is harder to read. We allow up to 119 characters as this is the width of GitHub code review; anything longer requires horizontal scrolling which makes review more difficult. This check is included when you run flake8. Documentation, comments, and docstrings should be wrapped at 79 characters, even though PEP 8 suggests 72.
  • 줄 길이에 대한 PEP 8 예외가 있습니다. 코드가 아주 보기 싫게 되거나 읽기 힘들어지는 것이 아니라면 줄 길이를 79자로 제한하지 마세요. 119자까지 허용하는데 이것은 GitHub 코드 리뷰의 넓이입니다; 더 길어지면 수평 스크롤을 해야 하기 때문에 리뷰가 불편해집니다. flake 을 실행하면 줄 길이 검사를 합니다. PEP 8 이 72자를 제안하기는 하지만 문서, 주석 그리고 docstrings 는 79자에서 줄 바꿈이 됩니다.
  • - Use four spaces for indentation.
  • 들여쓰기는 4개의 스페이스를 사용하세요.
  • - Use underscores, not camelCase, for variable, function and method names (i.e. poll.get_unique_voters(), not poll.getUniqueVoters()).
  • 변수, 함수, 메소드명에는 밑줄(언더스코어)을 사용하세요. 카멜케이스는 사용하지 마세요.

    (예: poll.getUniqueVoters()가 아닌 poll.get_unique_voters()를 쓰세요)
  • - Use InitialCaps for class names (or for factory functions that return classes).
  • 클래스를 반환하는 팩토리 함수 혹은 클래스 이름은 머릿글자를 대문자로 쓰세요.
  • - In docstrings, follow PEP 257. For example:
  • 문서화는 PEP 257를 따르세요. 예를 들면.
  • def foo(): """ Calculate something and return the result. """ ...
  • - In tests, use assertRaisesMessage() instead of assertRaises() so you can check the exception message. Use assertRaisesRegex() only if you need regular expression matching.
  • 테스트에서는 assertRaises() 대신에 assertRaisesMessage()를 사용하세요. 그러면 예외 메시지를 확인할 수 있습니다. 정규표현식 매칭이 필요하면, assertRaisesRegex()를 쓰세요.
  • - In test docstrings, state the expected behavior that each test demonstrates. Don’t include preambles such as “Tests that” or “Ensures that”.
  • 테스트 문서화에서는 각 테스트가 보여줄 것으로 예상되는 행동을 써주세요. "테스트는" 혹은 "보증하는" 과 같은 서문을 포함하지 마세요.
  • Reserve ticket references for obscure issues where the ticket has additional details that can’t be easily described in docstrings or comments. Include the ticket number at the end of a sentence like this:
  • 문서화 또는 주석으로 쉽게 설명할 수 없는 경우 모호한 문제일 경우, 추가 세부사항을 담고 있는 티켓 참조를 남기세요. 다음과 같이 문장의 끝에 티켓 번호를 포함 시키세요.
  • def test_foo(): """ A test docstring looks like this (#123456). """ ...
  • Imports

  • 임포트

  • - Use isort to automate import sorting using the guidelines below.
  • - 아래의 가이드라인을 따라 임포트 정렬을 자동화하기위해 isort를 사용하세요
  • Quick start:
  • 퀵 스타트
  • $ pip install isort $ isort -rc .
  • This runs isort recursively from your current directory, modifying any files that don’t conform to the guidelines. If you need to have imports out of order (to avoid a circular import, for example) use a comment like this:
  • 이 명령은 현재의 디렉토리에서 재귀적으로 isort를 실행한다. 가이드라인을 따르지 않는 파일들을 수정한다. 만약에 순서에 상관없는 임포트(예를 들어 순환 임포트를 피하기 위해서)를 해야한다면 다음과 같은 코멘트를 사용한다.
  • import module # isort:skip
  • - Put imports in these groups: future, standard library, third-party libraries, other Django components, local Django component, try/excepts. Sort lines in each group alphabetically by the full module name. Place all import module statements before from module importobjects in each section. Use absolute imports for other Django components and relative imports for local components.
  • - 임포트들을 다음 그룹안에 넣으세요: future모듈, 표준 라이브러리, 써드파티 라이브러리, 다른 장고 컴포넌트, 장고 로컬 컴포넌트, 예외(try/excepts). 각 그룹의 행을 모듈 전체 이름으로 정렬하세요. 각섹션의 모든 모듈 임포트를 임포트 된 오브젝트가 쓰이기 전에 전에 두세요. 다른 장고 컴포넌트는 절대 경로로 임포트하고 로컬의 다른 컴포넌트는 상대경로로 임포트하세요.
  • note icon
    future를 뭐라고 번역해야할지 잘 모르겠어요
    future 모듈?
    ㄴ반영하였사옵니다
  • - On each line, alphabetize the items with the upper case items grouped before the lower case items.
  • - 각 행을 알파벳 순으로 정렬하돼, 대문자가 소문자 보다 앞에 오게 하세요
  • - Break long lines using parentheses and indent continuation lines by 4 spaces. Include a trailing comma after the last import and put the closing parenthesis on its own line.
  • - 긴 행은 괄호와 이어진 줄의 4칸의 스페이스로 이루어진 들여 쓰기를 이용해서 개행하세요. 임포트 뒤에 트레일링 콤마를 찍고 괄호를 닫으세요. 단 닫는 괄호가 있는 줄에는 닫는 괄호 외의 문자를 삽입하지 마세요.
  • Use a single blank line between the last import and any module level code, and use two blank lines above the first function or class.
  • 서로 다른 레벨의 모듈의 마지막 임포트 사이에 빈 행을 사용하세요. 그리고 첫 함수나 클래스 위에는 두 개의 빈 행을 사용하세요
  • For example (comments are for explanatory purposes only):
  • 예시 (주석은 단지 설명을 위한 용도입니다):
  • django/contrib/admin/example.py
  • # future from __future__ import unicode_literals # standard library import json from itertools import chain # third-party import bcrypt # Django from django.http import Http404 from django.http.response import ( Http404, HttpResponse, HttpResponseNotAllowed, StreamingHttpResponse, cookie, ) # local Django from .models import LogEntry # try/except try: import yaml except ImportError: yaml = None CONSTANT = 'foo' class Example(object): # ...
  • - Use convenience imports whenever available. For example, do this:
  • - 가능하다면 간편한 임포트(convenience imports)를 사용하세요. 예를들면 이런식입니다
  • from django.views import View
  • instead of:
  • 위 코드가 아래의 코드보다 낫습니다
  • note icon
    번역 툴의 한계로 문단의 순서를 바꿀 수 없는게 한이네요
  • from django.views.generic.base import View
  • Template style

  • 템플릿 스타일

  • - In Django template code, put one (and only one) space between the curly brackets and the tag contents.
  • Django 템플릿 코드 내에서 중괄호와 태그 콘텐츠 사이에는 하나의 공백을 넣어주세요.
  • Do this:
  • 이렇게 하세요.
  • {{ foo }}
  • Don’t do this:
  • 이렇게 하지 마세요.
  • {{foo}}
  • View style

  • 뷰 스타일

  • - In Django views, the first parameter in a view function should be called request.
  • Django 뷰일 경우, 뷰 함수 첫번째 파라미터는 request를 써야 합니다.
  • Do this:
  • 이렇게 쓰세요.
  • def my_view(request, foo): # ...
  • Don’t do this:
  • 이렇게 하지 마세요.
  • def my_view(req, foo): # ...
  • Model style

  • 모델 스타일

  • - Field names should be all lowercase, using underscores instead of camelCase.
  • 필드명은 카멜케이스 대신 밑줄 문자와 소문자를 사용해 주세요.
  • Do this:
  • 이렇게 하세요.
  • class Person(models.Model): first_name = models.CharField(max_length=20) last_name = models.CharField(max_length=40)
  • Don’t do this:
  • 이렇게 하지 마세요.
  • class Person(models.Model): FirstName = models.CharField(max_length=20) Last_Name = models.CharField(max_length=40)
  • - The class Meta should appear after the fields are defined, with a single blank line separating the fields and the class definition.
  • class Meta는 필드 정의 다음에 나와야 합니다. 필드와 클래스 정의 사이에는 빈 한줄을 넣으세요.
  • Do this:
  • 이렇게 하세요.
  • class Person(models.Model): first_name = models.CharField(max_length=20) last_name = models.CharField(max_length=40) class Meta: verbose_name_plural = 'people'
  • Don’t do this:
  • 이렇게 하지 마세요.
  • class Person(models.Model): first_name = models.CharField(max_length=20) last_name = models.CharField(max_length=40) class Meta: verbose_name_plural = 'people'
  • Don’t do this, either:
  • 이렇게도 하지 마세요.
  • class Person(models.Model): class Meta: verbose_name_plural = 'people' first_name = models.CharField(max_length=20) last_name = models.CharField(max_length=40)
  • - The order of model inner classes and standard methods should be as follows (noting that these are not all required):
  • 모델 내부의 클래스와 표준 메소드의 순서는 아래의 순서를 따르세요. (모두 필수는 아니에요):
  • - All database fields
  • 모든 데이터베이스 필드
  • - Custom manager attributes
  • 커스텀 매니저 속성
  • - class Meta
  • class Meta
  • - def __str__()
  • def __str__()
  • - def save()
  • def save()
  • - def get_absolute_url()
  • def get_absolute_url()
  • - Any custom methods
  • 그외 커스텀 메소드들
  • - If choices is defined for a given model field, define each choice as a tuple of tuples, with an all-uppercase name as a class attribute on the model. Example:
  • 모델 필드의 초이스 값을 정의할 때, 각각의 초이스는 튜플의 튜플로 정의합니다. 모델의 클래스 속성처럼 모두 대문자로 작성해주세요. 예:
  • class MyModel(models.Model): DIRECTION_UP = 'U' DIRECTION_DOWN = 'D' DIRECTION_CHOICES = ( (DIRECTION_UP, 'Up'), (DIRECTION_DOWN, 'Down'), )
  • Use of django.conf.settings

  • django.conf.settings 의 이용

  • Modules should not in general use settings stored in django.conf.settings at the top level (i.e. evaluated when the module is imported). The explanation for this is as follows:
  • 모듈은 일반적으로(모듈이 평가될 때) 최상위 레벨에 저장된 django.conf.settings을 사용하지 않아야 합니다. 이에 대한 설명으로는 아래를 참조하세요.
  • Manual configuration of settings (i.e. not relying on the DJANGO_SETTINGS_MODULE environment variable) is allowed and possible as follows:
  • 아래 코드와 같은 수동 configuration 설정(DJANGO_SETTINGS_MODULE 환경변수에 의존하지 않는 경우)은 허용됩니다.
  • from django.conf import settings settings.configure({}, SOME_SETTING='foo')
  • However, if any setting is accessed before the settings.configure line, this will not work. (Internally, settings is a LazyObjectwhich configures itself automatically when the settings are accessed if it has not already been configured).
  • 그러나, 어떤 경우에도 settings.configure 행 이전에 settings 에 접근할 수 없습니다. (내부적으로 settings 는 LazyObject로 settings이 생성 되기 전에 접근 시 자동으로 생됩니다.)
  • So, if there is a module containing some code as follows:
  • 그래서 다음과 같은 모듈을 포함하는 코드가 있다면:
  • from django.conf import settings from django.urls import get_callable default_foo_view = get_callable(settings.FOO_VIEW)
  • ...then importing this module will cause the settings object to be configured. That means that the ability for third parties to import the module at the top level is incompatible with the ability to configure the settings object manually, or makes it very difficult in some circumstances.
  • ... 이 모듈을 포함하면 settings 객체를 구성하게 될 것입니다. 즉 제 3자가 모듈을 최상위 레벨에서 임포트 하는 기능과 settings 객체를 수동으로 구성하는 기능은 서로 호환되지 않거나 어떤 상황에서 매우 어려울 수 있습니다.
  • Instead of the above code, a level of laziness or indirection must be used, such as django.utils.functional.LazyObject,django.utils.functional.lazy() or lambda.
  • 위 코드 대신에 django.utils.functional.LazyObject,django.utils.functional.lazy() 나 람다와 같은 lazy한 레벨이나 우회적인 방법이 쓰여야만 합니다
  • Miscellaneous

  • 잡다한 것들

  • - Mark all strings for internationalization; see the i18n documentation for details.
  • - 국제화를 위해 모든 문자열을 표시하세요. 자세한 것은 i18n documentation문서를 확인하세요.
  • - Remove import statements that are no longer used when you change code. flake8 will identify these imports for you. If an unused import needs to remain for backwards-compatibility, mark the end of with # NOQA to silence the flake8 warning.
  • - 코드를 변경 하면서 더이상 사용 되지 않는 임포트 구문을 지우세요. flake8은 당신을 위해 임포트들을 확인 해 줄 것입니다. 만약 이전 버전과 호환성을 위해 사용하지 않는 임포트를 남겨 두어야 할 경우, 끝에 # NOQA 코멘트를 표시해 주세요. flake8이 더이상 에러를 표시하지 않을 것입니다.
  • - Systematically remove all trailing whitespaces from your code as those add unnecessary bytes, add visual clutter to the patches and can also occasionally cause unnecessary merge conflicts. Some IDE’s can be configured to automatically remove them and most VCS tools can be set to highlight them in diff outputs.
  • - 체계적으로 모든 후행 공백을 코드 내에서 지우세요. 불필요한 bytes를 추가하고 수정 시 시각적인 혼란을 주며 병합시 불필요한 충돌을 발생시킵니다. 몇몇 IDE는 자동으로 그런 불필요한 공백들을 지우도록 설정 할 수 있으며, 버전 관리 시스템은 공백들을 diff 아웃풋에서 표시합니다.
  • - Please don’t put your name in the code you contribute. Our policy is to keep contributors’ names in the AUTHORS file distributed with Django – not scattered throughout the codebase itself. Feel free to include a change to the AUTHORS file in your patch if you make more than a single trivial change.
  • - 기여한 코드에 이름을 넣지 마세요. 우리는 장고와 함께 배포되는 AUTHORS 파일에 기여자의 이름을 남기는 정책을 유지 하고 있습니다. 코드 베이스에 여기저기 흩어두지 않습니다. 사소한 변경을 한번이라도 수행했다면 마음놓고 AUTHORS 이름을 파일에 포함시키세요
  • JavaScript style

  • 자바스크립트 스타일

  • For details about the JavaScript code style used by Django, see JavaScript.
  • 장고에서 사용 되는 자바스크립트 코드 스타일의 세부 사항은 자바스크립트 를 참고하세요
1 Comment
whatistheyoon

whatistheyoon • Mar 11th, 2017

> 번역 툴의 한계로 문단의 순서를 바꿀 수 없는게 한이네요

@fb8454125932107
문단에 어떻게 변경되기를 원하셔요?