존중하는 코드
포용성은 V8 문화의 중심이며, 우리의 가치는 서로를 존엄하게 대하는 것을 포함합니다. 따라서, 누구나 편향과 차별의 유해한 영향을 받지 않고 기여할 수 있는 것이 중요합니다. 그러나, 코드베이스, UI, 문서 내의 용어는 이 차별을 지속할 수 있습니다. 이 문서는 코드와 문서에서 존중되지 않는 용어를 다루기 위한 지침을 제시합니다.
정책
직접적이든 간접적이든 경멸적이고 상처를 주거나 차별을 유지시키는 용어는 피해야 합니다.
이 정책의 적용 범위는 무엇입니까?
V8 작업 중 기여자가 읽게 되는 모든 내용은 다음을 포함합니다:
- 변수, 유형, 함수, 파일, 빌드 규칙, 바이너리, 내보낸 변수 등의 이름
- 테스트 데이터
- 시스템 출력 및 디스플레이
- 문서 (소스 파일 내부와 외부 모두 포함)
- 커밋 메시지
원칙
- 존중하기: 경멸적인 언어는 작동 방식을 설명하는 데 필요하지 않아야 합니다.
- 문화적으로 민감한 언어 존중: 일부 단어는 중요한 역사적 또는 정치적 의미를 가질 수 있습니다. 이를 유념하고 대체어를 사용하세요.
특정 용어가 허용될 수 있는지 어떻게 알 수 있습니까?
위의 원칙을 적용하세요. 질문이 있다면 [email protected]으로 연락하실 수 있습니다.
피해야 할 용어의 예는 무엇입니까?
이 목록은 포괄적이지 않습니다. 사람들이 자주 마주한 몇 가지 예를 포함하고 있습니다.
용어 | 제안된 대체어 |
---|---|
master | primary, controller, leader, host |
slave | replica, subordinate, secondary, follower, device, peripheral |
whitelist | allowlist, exception list, inclusion list |
blacklist | denylist, blocklist, exclusion list |
insane | unexpected, catastrophic, incoherent |
sane | expected, appropriate, sensible, valid |
crazy | unexpected, catastrophic, incoherent |
redline | priority line, limit, soft limit |
이 정책을 위반하는 대상을 사용할 경우 어떻게 해야 합니까?
이 상황은 특히 사양을 구현하는 코드에서 몇 번 발생했습니다. 이러한 경우, 사양의 언어와 다르게 사용하면 구현을 이해하는데 방해가 될 수 있습니다. 이러한 상황에서는 다음을 권장합니다. 선호도가 낮은 순서대로 나열되었습니다:
- 대체 용어를 사용해도 이해에 방해가 되지 않는다면, 대체 용어를 사용하세요.
- 그게 안 된다면, 인터페이스를 수행하는 코드 레이어 이상으로 용어를 전파하지 마세요. 필요한 경우, API 경계에서 대체 용어를 사용하세요.