秉持尊重之心进行编码

包容性是 Android 文化的核心，我们的价值观包括以尊严对待彼此。因此，每个人都必须能够在免受偏见和歧视有害影响的情况下做出贡献。但是，我们代码库、用户界面和文档中的术语可能会使这种歧视长期存在。本政策旨在指导如何解决代码、界面和文档中不尊重的术语问题。

如需详细了解 Android 标准，请参阅行为准则。

政策

应避免使用直接或间接具有贬损性、伤害性或使歧视长期存在的术语。这与 Google 关于编写包容性文档的指南一致。

本政策的适用范围

本政策的范围包括贡献者在处理 Android 时会阅读的任何内容，包括但不限于：

  • 变量、类型、函数、文件、构建规则、二进制文件、导出的变量的名称
  • 测试数据
  • 系统输出和显示
  • 注释和文档（源代码文件内部和外部的注释和文档）
  • 提交消息

原则

  • 保持尊重：不应需要使用贬损性语言来描述事物的运作方式。
  • 使用符合文化习惯的语言：有些词可能具有重要的历史或政治含义。请考虑这一点并使用替代词。

确定特定术语是否合适

应用上述原则。如有任何疑问，您可以联系 android-community@googlegroups.com。

要避免使用的术语示例

此列表并非旨在详尽无遗。其中包含一些人们经常遇到的示例。

请注意，始终值得考虑注释是否添加了任何价值。有时，最好的修复方法是完全删除注释。例如，在名为 verify_header 的函数紧前面添加一个仅说“Sanity check the header”的注释，即使您正在为公共 API 编写文档注释，也不会添加任何价值。请更具体地说明要检查的内容，例如“Check header for out of range values”。

术语 建议的替代方案
master/slave 请参阅 master 和 slave 的替代方案。
redline 优先级线、跟踪更改、设计规范、UI 注释、异常、异常情况、特殊情况、替换列表
whitelist/blacklist 请参阅 blacklist 的替代方案。
(dark|light) graylist 对于 API
  • (graylist) “非 SDK API 列表”
  • (dark-graylist) 指的是所有 max-target-sdk 列表的组合时，使用“有条件地阻止”；指的是特定列表时，使用“max-target-X”
  • (light-graylist) “不受支持”
crazy、insane、cripple 有关指南，请参阅避免歧视残疾人的语言。
sanity check 仅“check”一词通常就传达了相同的含义。否则，请考虑 validate、verify、quick check、initial check、confidence check、soundness check、calibration check、readiness check。
dummy unused、placeholder、no-op、base、fake/mock/stub。
grandfathered 有关指南，请参阅 grandfathered 的替代方案。
带性别的代词（例如，he 或 she） they、them、their
man-in-the-middle (MITM) 路径攻击者
(black|white|gray) hat 符合道德规范/不符合道德规范
first-class citizen 核心功能、内置、顶层

更改语言会改变含义时

在某些情况下，更改规范中的语言可能会干扰理解实现的能力，尤其是在实现代码规范时。对于这些情况，我们按偏好程度降序建议以下方法之一：

  1. 如果使用替代术语不会干扰理解，请使用替代术语。
  2. 不要在执行接口操作的代码层之外传播术语。必要时，在 API 边界使用替代术语。
  3. 如果您自己无法修复语言问题，请向相应团队提交错误。