Programar com respeito

A inclusão é essencial para a cultura do Android, e nossos valores incluem tratar uns aos outros com dignidade. Por isso, é importante que todos possam contribuir sem enfrentar os efeitos prejudiciais da parcialidade e da discriminação. No entanto, os termos do nosso codebase, as interfaces do usuário e a documentação podem perpetuar essa discriminação. Esta política oferece orientação para lidar com a terminologia desrespeitosa em código, interfaces e documentação.

Política

Termos que sejam depreciativos, ofensivos ou que perpetuem discriminação, seja ela direta ou indireta, precisam ser evitados. Essa é a orientação do Google sobre como redigir uma documentação inclusiva.

O que está no escopo desta política?

Tudo o que um colaborador leria ao trabalhar no Android, incluindo, entre outros:

  • Nomes de variáveis, tipos, funções, arquivos, regras de compilação, binários, variáveis exportadas
  • Dados de teste
  • Saída e exibições do sistema
  • Comentários e documentação (dentro e fora dos arquivos de fonte)
  • Mensagens de confirmação

Princípios

  • Demonstre respeito: uma linguagem depreciativa não é necessária para descrever como as coisas funcionam.
  • Use uma linguagem culturalmente adequada: algumas palavras podem ter significados históricos ou políticos importantes. Considere isso e use alternativas.

Como posso saber se uma terminologia específica está correta?

Aplique os princípios acima. Se tiver alguma dúvida, entre em contato com android-community@googlegroups.com.

Que exemplos de terminologia devem ser evitados?

Esta NÃO é uma lista completa. Ela contém alguns exemplos que as pessoas encontram com frequência.

É sempre importante considerar se um comentário agrega algum valor. Às vezes, a melhor solução é removê-lo completamente. Por exemplo, um comentário que diz apenas "Verifique a integridade do cabeçalho" imediatamente antes de uma função chamada verify_header não agrega nenhum valor, mesmo que você esteja escrevendo o comentário de documento para uma API pública. Forneça informações mais específicas sobre o que precisa ser verificado. Por exemplo: "Verifique se não há valores fora do intervalo no cabeçalho".

Termo Alternativas sugeridas
mestre/escravo principal/réplica, principal/secundário, líder/seguidor, controlador/agente, gerente/trabalhador, misturador/folha, agregador/coletor, editor/assinante, iniciador/resposta automática
linha vermelha linha de prioridade, controle de alterações, especificações de design, anotações de IU, exceção, anomalia, caso especial, lista de substituição
lista branca lista de permissões, permitido, lista de inclusão, lista segura
lista negra lista de negações, bloqueado, lista de exclusão, lista de bloqueio
lista cinza (escuro|claro) Para APIs:
  • (lista cinza) "listas de APIs não SDK", "listas de APIs ocultas"
  • (lista cinza-escuro) "itens bloqueados condicionalmente" ou alvo máximo X ao se referir a uma lista específica
  • (lista cinza-claro) "itens não recomendados", "itens temporários"
louco, insano, inválido Consulte as diretrizes em Evitar linguagem capacitista.
verificação de sanidade A palavra "verificação" sozinha transmite o mesmo significado. Caso contrário, considere usar validação, confirmação, verificação rápida, verificação inicial, verificação de confiança, verificação de solidez, verificação de calibragem, verificação de prontidão.
dummy não utilizado, marcador, ambiente autônomo, base, falso/simulado/stub.
grandfathering isenção, já existente, retenção, transferência, valor de referência, legado
pronomes que determinam gênero (por exemplo, ele ou ela) eles, eles, seus
atravessador invasor
chapéu (preto|branco|cinza) ético/antiético
cidadão de primeira classe recurso principal, integrado, nível superior

E se eu estiver interagindo com algo que viole esta política?

Essa situação já ocorreu algumas vezes, especialmente na especificação para a implementação de código. Nessas circunstâncias, uma linguagem na especificação pode interferir na capacidade de entendimento da implementação. Para essas circunstâncias, sugerimos uma das seguintes opções, em ordem decrescente de preferência:

  1. Se o uso da terminologia alternativa não interferir no entendimento, use a terminologia alternativa.
  2. Não propague a terminologia além da camada de código que está realizando a interface. Quando necessário, use uma terminologia alternativa nos limites da API.
  3. Se você não conseguir corrigir a linguagem, registre um bug com a respectiva equipe.