Closed zerosheepmoo closed 3 years ago
1차 검토 완료하였습니다!
trailing 은 후행으로 번역하는 것이 일반적이나, leading 같은 경우, 가독성으로 인해 저는 첫 글자
로 번역을 해왔는데요.
trailing 과 매칭되게 선행으로 번역하는 것이 좋을지 고민입니다.
2차 검토하시는 분이 의견 달아주세요 👍
단어 | 뜻 |
---|---|
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 | 규정 |
@zerosheepmoo , @Sumin0916 2차 검토 코멘트 모두 달았어요. 확인 부탁드립니다 😄 (#20가 #39 로 통합 커밋에 있습니다)
Python 라이브러리의 작명 컨벤션은 좀 망쳐져 있다. 그래서 앞으로도 절대 완벽하게 일관성 있게 유지할 수는 없다. 그럼에도 불구하고 권장하는 작명 기준을 소개한다.
다양한 작명 스타일이 존재한다. 이는 작명 스타일의 용도와는 별개로 어떤 작명 스타일이 사용되는지 깨닫게 도와준다. 일반적으로 다음과 같이 분류한다.
CapitalizedWords
(또는 CapWords[^1], CamelCase 라고 불리운다. 글자의 울퉁불퉁한 모양 때문에 그렇게 이름이 붙여졌다.[^2]) 이는 StudlyCaps로 라고도 불리운다.
mixedCase
(단어 첫 글자가 소문자로 CapitalizedWords와는 다르다!)
X11 라이브러리는 모든 퍼블릭 함수에 첫글자 X를 사용한다. Python에서 이 스타일은 일반적으로 불필요하다고 간주된다. 왜냐하면 Python에서는 어트리뷰트명과 메소드명은 오브젝트명으로 접두어를 붙이고, 함수명은 모듈명으로 접두어를 붙이기 때문이다.
~의 이름
이 너무 길고 눈에 안들어왔습니다. 이미 최대한 ~명
을 쓰기로 합의되었으므로 이로 수정했습니다.
_single_leading_underscore
: 약한 "내부 사용" 지표(indicator).
패키지명과 모듈명
모듈명은 모두 소문자를 사용하여 짧게 지어야한다. 밑줄(Underscores)은 가독성 향상을 위해 사용될 수 있다.
패키지명은 또한 모두 소문자를 사용하여 짧게 지어야한다. 단, 밑줄은 권장되지 않는다.
~명
사용을 최대한 늘렸습니다.Python 에서의
에 해당하는 부분은 의미반복이므로 한국어문에서는 가독성향상을 위해 삭제했습니다.대부분의 내장 된 클래스명은 단일 단어(또는 두 개의 단어가 결합된 혼성어)다. CapWords 컨벤션은 예외(exception)명이나 내장 상수에만 사용된다.
run
은 실행하다가 아닌 같이 딸려오는 정도의 의미로 해석하는 것이 옳아보입니다.~명
을 사용하였습니다.(이 변수들이 하나의 모듈 안에서만 있다고 가정하자)
이 경우 작명 컨벤션은 함수에 대한 컨벤션과 같다.
from M import *
를 사용하기 위해 설계된 모듈들은__all__
메커니즘을 사용해야 한다. 그럼으로써 전역변수 내보내기를 하는 것을 막아야 한다.또는 밑줄을 접두어로 넣는 오래된 컨벤션을 사용하자.
mixedCase 는 이미 스타일이 존재하는 컨텍스트(예를 들면,
threading.py
)에만 허용된다.
함수 작명 규칙처럼, 소문자를 사용하고 가독성 향상을 위해 밑줄로 단어를 구분하자.
항상 클래스 메소드와 인스턴스 변수(통칭: "어트리뷰트")가 퍼블릭인지 아닌지 결정하라. 만약 결정되지 않았다면, 퍼블릭이 아닌 컨벤션을 골라라. 나중에 퍼블릭으로 바꾸는 것이 퍼블릭을 아닌 것으로 바꾸는 거보다 더 쉽다.
퍼블릭 어트리뷰트는 하위 호환성을 유지하려는 노력과 함께, 당신이 만든 클래스와 관련없는 클라이언트가 사용할 예정인 어트리뷰트다. 퍼블릭이 아닌 어트리뷰트는 외부에서 사용되게끔 의도하지 않는 어트리뷰트다. 그래서 퍼블릭이 아닌 어트리뷰트가 앞으로 바뀌거나 제거되지 않을 것이라는 보장을 하지 말아야된다.
우리는 "프라이빗(private)"이라는 용어를 사용하지 않는다. 왜냐하면 어떠한 어트리뷰트도 실제 Python 에서는 프라이빗일 수 없기 때문이다. (일반적으로 불필요한 양의 추가 작업 없이는 실제 프라이빗으로 만들 수 없다.)
몇 클래스는 클래스의 행위의 측면에서 확장 또는 수정(modify)하기 위해 상속 받도록 설계되었다.
이를 명심하며, 다음의 Python스러운 가이드라인을 살펴보자.
(하지만 예외도 있다.
'cls'
는 클래스를 나타내는 변수 또는 아규먼트로, 특히 클래스 메소드의 첫번째 아규먼트로도 바람직한 철자다.)
기능적 행위(functional behavior)을 확장해야하는 경우, 향후 향상(enhancement)을 위한 쉬운 길을 제공하고 있다는 것을 명심하자.
인터페이스를 갖고 있는 네임스페이스(패키지, 모듈, 또는 클래스)가 내부(internal)로 간주될 경우 또한 내부 인터페이스로 간주된다.
가져오기 된 이름은 구현 세부사항으로 항상 간주되어야 한다. 이를 포함하는 모듈의 API의 명시적으로 문서화 된 부분이 아닌 한, 다른 모듈들은 가져오기 된 이름으로의 간접적인 접근에 의존하지 않아야한다.
참여자
Descriptive: Naming Styles
Descriptive: Naming Styles 제외
목록