search

zerosheepmoo / pep8-in-korean

pep8 korean translation
MIT License
8 stars 3 forks source link

PEP8 번역 - Naming Conventions #39

Closed zerosheepmoo closed 3 years ago

zerosheepmoo commented 3 years ago

참여자

Descriptive: Naming Styles

Descriptive: Naming Styles 제외

목록

Sumin0916 commented 3 years ago

1차 검토 완료하였습니다!

zerosheepmoo commented 3 years ago

Descriptive: Naming styles 에 대해

1차 검토 내역

토론

trailing 은 후행으로 번역하는 것이 일반적이나, leading 같은 경우, 가독성으로 인해 저는 첫 글자로 번역을 해왔는데요. trailing 과 매칭되게 선행으로 번역하는 것이 좋을지 고민입니다. 2차 검토하시는 분이 의견 달아주세요 👍

zerosheepmoo commented 3 years ago

단어 추출 목록

단어 뜻
feature 기능, 특징
standard 표준, 기준
descriptive 설명(문)
overriding 오버라이딩
independently 별개로, 분리되어, 독립적으로
distinguish 구분
capitalize 첫 글자를 대문자로 바꾸기
acronyms 약어
prefix 접두어, 접두사
suffix 접미어, 접미사
mentione 언급하다
correspondence 연관성
emphasize 강조하다
underscore 밑줄
leading 선행, 첫 글자 ~
ASCII ascii, 아스키
internal 내부
indicator 지시자, 지표
mangling 맹글링
magic 매직
documented 문서화된
package 패키지
module 모듈
lowercase 소문자
uppercase 대문자
numerals 숫자
class 클래스
interface 인터페이스
embed 내장하다
compatible 호환성 / 호환되는
describe 설명하다
accompanying 동반하는
discouraged 권장되지 않는
prefered 권장하는, 바람직한
callable callable
caller 호출자
callee 피호출자
exception 예외
type 타입, 종류
builtin 내장
constant(s) 상수
covariant 공변(성)
contravariant 반변(성)
behavior 행위
naming 작명(하는)
global 전역, 전역적인, 글로벌
local 로컬, 지역, 국지적인
import 가져오기
syntax 구문, 문법
mechanism 메커니즘
function 기능, 함수
name 이름, 명
synonym 동의어
instance 인스턴스
method 메소드
non-public 퍼블릭이 아닌
client 클라이언트
access 접근하다
private 프라이빗
invoke 호출하다
call 호출하다
subclass 하위클래스, 자식클래스
third parties 서드 파티, 외부
enhancement 향상
improvement 향상
collides 충돌하다
expose 노출하다
path 경로
implementation 구현
side-effect 사이드 이펙트
caching 캐싱
debugging 디버깅
manually 메뉴얼하게, 수동적으로
potential 잠재적인
API API
guarantee 보장하다
ensure 보장하다
detail 상세, 세부사항
export 내보내기
prescriptive 규정

hajun-myoung commented 3 years ago

@zerosheepmoo , @Sumin0916 2차 검토 코멘트 모두 달았어요. 확인 부탁드립니다 😄 (#20가 #39 로 통합 커밋에 있습니다)

zerosheepmoo commented 3 years ago

3차 검토 내역

Python 라이브러리의 작명 컨벤션은 좀 망쳐져 있다. 그래서 앞으로도 절대 완벽하게 일관성 있게 유지할 수는 없다. 그럼에도 불구하고 권장하는 작명 기준을 소개한다.

다양한 작명 스타일이 존재한다. 이는 작명 스타일의 용도와는 별개로 어떤 작명 스타일이 사용되는지 깨닫게 도와준다. 일반적으로 다음과 같이 분류한다.

  • CapitalizedWords (또는 CapWords[^1], CamelCase 라고 불리운다. 글자의 울퉁불퉁한 모양 때문에 그렇게 이름이 붙여졌다.[^2]) 이는 StudlyCaps로 라고도 불리운다.
  • mixedCase (단어 첫 글자가 소문자로 CapitalizedWords와는 다르다!)

X11 라이브러리는 모든 퍼블릭 함수에 첫글자 X를 사용한다. Python에서 이 스타일은 일반적으로 불필요하다고 간주된다. 왜냐하면 Python에서는 어트리뷰트명과 메소드명은 오브젝트명으로 접두어를 붙이고, 함수명은 모듈명으로 접두어를 붙이기 때문이다.

  • _single_leading_underscore: 약한 "내부 사용" 지표(indicator).

패키지명과 모듈명

모듈명은 모두 소문자를 사용하여 짧게 지어야한다. 밑줄(Underscores)은 가독성 향상을 위해 사용될 수 있다.

패키지명은 또한 모두 소문자를 사용하여 짧게 지어야한다. 단, 밑줄은 권장되지 않는다.

대부분의 내장 된 클래스명은 단일 단어(또는 두 개의 단어가 결합된 혼성어)다. CapWords 컨벤션은 예외(exception)명이나 내장 상수에만 사용된다.

(이 변수들이 하나의 모듈 안에서만 있다고 가정하자)

이 경우 작명 컨벤션은 함수에 대한 컨벤션과 같다.

from M import * 를 사용하기 위해 설계된 모듈들은 __all__ 메커니즘을 사용해야 한다. 그럼으로써 전역변수 내보내기를 하는 것을 막아야 한다.

또는 밑줄을 접두어로 넣는 오래된 컨벤션을 사용하자.

mixedCase 는 이미 스타일이 존재하는 컨텍스트(예를 들면, threading.py)에만 허용된다.

함수 작명 규칙처럼, 소문자를 사용하고 가독성 향상을 위해 밑줄로 단어를 구분하자.

항상 클래스 메소드와 인스턴스 변수(통칭: "어트리뷰트")가 퍼블릭인지 아닌지 결정하라. 만약 결정되지 않았다면, 퍼블릭이 아닌 컨벤션을 골라라. 나중에 퍼블릭으로 바꾸는 것이 퍼블릭을 아닌 것으로 바꾸는 거보다 더 쉽다.

퍼블릭 어트리뷰트는 하위 호환성을 유지하려는 노력과 함께, 당신이 만든 클래스와 관련없는 클라이언트가 사용할 예정인 어트리뷰트다. 퍼블릭이 아닌 어트리뷰트는 외부에서 사용되게끔 의도하지 않는 어트리뷰트다. 그래서 퍼블릭이 아닌 어트리뷰트가 앞으로 바뀌거나 제거되지 않을 것이라는 보장을 하지 말아야된다.

우리는 "프라이빗(private)"이라는 용어를 사용하지 않는다. 왜냐하면 어떠한 어트리뷰트도 실제 Python 에서는 프라이빗일 수 없기 때문이다. (일반적으로 불필요한 양의 추가 작업 없이는 실제 프라이빗으로 만들 수 없다.)

몇 클래스는 클래스의 행위의 측면에서 확장 또는 수정(modify)하기 위해 상속 받도록 설계되었다.

이를 명심하며, 다음의 Python스러운 가이드라인을 살펴보자.

(하지만 예외도 있다. 'cls'는 클래스를 나타내는 변수 또는 아규먼트로, 특히 클래스 메소드의 첫번째 아규먼트로도 바람직한 철자다.)

기능적 행위(functional behavior)을 확장해야하는 경우, 향후 향상(enhancement)을 위한 쉬운 길을 제공하고 있다는 것을 명심하자.

인터페이스를 갖고 있는 네임스페이스(패키지, 모듈, 또는 클래스)가 내부(internal)로 간주될 경우 또한 내부 인터페이스로 간주된다.

가져오기 된 이름은 구현 세부사항으로 항상 간주되어야 한다. 이를 포함하는 모듈의 API의 명시적으로 문서화 된 부분이 아닌 한, 다른 모듈들은 가져오기 된 이름으로의 간접적인 접근에 의존하지 않아야한다.