Certa vez elaborei uma argumentação detalhada sobre usarmos código em português em uma empresa que tinha um domínio jurídico bastante específico. Me arrependi!
A ideia final era tentar preservar os padrões mais claros em inglês como “findBy“, “Factory“, etc. E no restante do código usar português para melhorar a legibilidade.
Funcionou, o código está lá até hoje e é bom. Mas a legibilidade ficou muito prejudicada e demorei para entender porque, por mais que eu me esforçasse, o código não saia legal.
Os nomes dos métodos, das variáveis e especialmente a sequencia de chamadas entre os métodos das nossas classes e dos códigos das bibliotecas ficava muito confuso.
Todas as bibliotecas, frameworks e componentes que usamos são em inglês. Sem exceção. TODO O CÓDIGO de terceiros é em inglês.
Fica impossível pensar em português se nós estamos todo o tempo chamando o entityManager, escrevendo “public class“. Não existe código em português. Você não consegue traduzir o framework, não consegue traduzir a biblioteca.
Então, na melhor das hipóteses o resultado de um código em português é um tipo de “Portunhol” entre Português e Inglês.
Minha experiência depois destes 14 anos é que código deve ser em inglês, justamente para que exista uma harmonia entre código de domínio, código de infraestrutura e código de terceiros.
Como lidar com as traduções dos termos?
Minha prática é, sempre diante de conceitos novos para a aplicação, criar a definição deles primeiro em documentos de texto, em português, sugerir então nomes em inglês para os termos mais relevantes e compartilhar com a equipe (hoje em dia eu frequentemente encontro primeiro o termo em inglês e acabo traduzindo para o português só para fins de documentação).
Isso gera um efeito legal porque para pensar no nome as pessoas precisam ler o conceito e entendê-lo, o que é ótimo para a saúde do entendimento de domínio.
Com o acordo em relação a tradução dos principais conceitos (quase sempre substantivos), sigo para implementação em inglês. Logo o conceito se consolida na equipe. Sempre que preciso relembrar algo retorno ao documento original.
Com as pessoas de negócio eu costumo também checar se os termos fazem sentido em inglês, esta checagem ajuda inclusive na validação do meu entendimento do conceito.
As únicas exceções são termos técnicos locais na legislação do país vigente, que não tem uma tradução adequada. Nesse caso estes termos são preservados no código como nomes próprios. Frequentemente estes termos tem siglas, e como siglas, não geram nenhum problema no código em inglês, como CPF, CNPJ, RG, etc.
Sobre coisas que não são código
Mensagens de commit, pull requests e comentários destinados à longas explicações do motivo de uma determinada decisão de código NÃO SÃO CÓDIGO e portanto, não se aplicam aqui.
Estas criações textuais frequentemente com informações de contexto e explicativas ao meu ver devem ser escritas na linguagem que o time domina melhor porque a expressividade da comunicação sutil é muito relevante. Mas se houver domínio suficiente do inglês, eu entendo que seria ideal adotar o inglês.