Programar em português ou inglês? Ou, de forma mais geral, programar ou não em minha língua nativa? Este é um tema recorrente em nossa área e, neste artigo, deixo minha opinião sobre o assunto.
PROGRAMANDO EM INGLÊS
Vamos começar com alguns argumentos bem fortes para se programar em inglês, sendo os 2 últimos relacionados ao contexto do projeto:
1. Uniformidade de código. Fica mais fluido ler algo totalmente em inglês, seguindo o padrão da própria linguagem de programação, cujas palavras-chave estão todas em inglês.
2. Facilidade de dar nomes. É bem mais natural dar nomes em inglês para objetos do tipo “Service Providers”, ou seja, aqueles objetos que simplesmente executam alguma tarefa (ex.: HtmlParser, MessageTranslator, EventHandler, etc…) e que, normalmente, tem um viés técnico (objetos relacionados a infraestrutura, frameworks, UI, ….)
3. Open Source. Se você está trabalhando em uma lib, ferramenta, framework open-source e quer que o alcance do mesmo seja mundial (usuários e colaboradores), é fundamental que o mesmo esteja em inglês.
4. Projetos de âmbito global. Se você trabalha em um tipo de software globalizado, faz todo sentido programar em inglês, uma vez que o negócio é exatamente o mesmo em qualquer lugar do mundo e fica mais fácil de manter o código uniforme mesmo com desenvolvedores de toda parte do globo.
QUANDO O RUÍDO COMEÇA
Imagine agora que o software seja corporativo, atendendo um domínio específico, como o jurídico. Nesta área, figuram termos como “Petição”, “Vara”, “Comarca”, “Jurisprudência”, “Parecer”, “Precatório” e tantos outros ainda mais complicados, dependendo da especialidade jurídica em questão. Você consegue traduzi-los de imediato? É bem provável que não, mesmo que você seja fluente em inglês.
E não se trata simplesmente de traduzir termos para outra língua. Eles precisam fazer sentido! E é aí que está o grande problema: a legislação brasileira não é igual à norte-americana ou de qualquer outro país de língua inglesa (e qual desses países você usaria como base?).
Na prática, o que “ganhamos” ao traduzir para o inglês um domínio assim são:
- Perda de tempo em busca da tradução (e, acreditem em mim, isso TOMA tempo);
- Traduções forçadas/confusas, porque o termo em questão não existe ou é muito difícil de se traduzir;
- E, inevitavelmente, você acabaria com uma mistura, mesmo que mínima, de português com inglês (*), Afinal, mesmo que você quisesse, como traduziria nomes de impostos, documentos e órgãos tipicamente brasileiros (ex. IPTU, TRT, …)?
No final das contas, teremos um código que não é claro e que perde valor por deixar de transmitir conhecimento de negócio.
(*) misturar português com inglês não é necessariamente um problema, como veremos mais abaixo.
NEM TUDO SÃO FLORES
Mesmo em um software corporativo, temos uma porção de serviços técnicos, à parte do código referente ao domínio de negócio. E, como dito inicialmente, nomear esses serviços é bem mais natural em inglês!
Se levarmos a questão para o outro extremo e traduzirmos todo o código para o português, acabaremos com nomes como “AdaptadorDeHttp”, “TratadorDeExceções”, “ObservadorDeEventos”, “ArmazenadorDeArquivos”, entre outros mais estranhos. Fora os casos onde será difícil ou impossível de traduzir, seja pelo termo técnico ser 100% conhecido/adotado em inglês, seja por convenções exigidas por frameworks.
Sendo assim, cairemos nas mesmas situações levantadas no tópico anterior: mistura de idiomas e nomes bizarros. O que fazer então?
UMA SOLUÇÃO (NÃO MUITO POPULAR)
Infelizmente não existe uma solução perfeita. É preciso ceder. De todas as alternativas que já usei, aquela que me agrada mais é usar o português em toda a camada de negócio (domínio) e para todo o restante, o inglês (sempre que possível).
Percebam que o “sempre que possível” anterior dá margem para o bom senso em casos onde o português comunica melhor a ideia.
Muitos podem achar que essa estratégia de mistura de idiomas deixa o código sem padrão ou, simplesmente, “feio”. Meu contraponto é que, antes de ser “bonito ou feio”, o código deve comunicar efetivamente o que ele faz.
Provavelmente (ou certamente?), “S3StorageAdapter” comunica bem seu propósito e é até mais curto do que “AdaptadorDeArmazenamentoNoS3” (ou algo parecido a isso). Assim como “AlvaraDeSoltura” comunica melhor seu propósito na linguagem do domínio do que seus equivalentes em inglês.
CONCLUSÃO
Repetindo: todo código deve comunicar efetivamente o que ele faz.
O principal ponto deste artigo é o de que forçar o uso do inglês em um domínio nacional e específico traz mais prejuízos do que ganhos porque transmite mal o conhecimento de negócio e gera problemas de comunicação (dev-dev, dev-negócio).
Robson Castilho 
Eu sigo uma linha de pensamento bem parecida com a sua na hora de escolher entre português e inglês.Se o meu projeto não tem regras de negócio que são específicas do país, eu uso o inglês e segue o jogo.
Agora se a regra de negócio for específica do país eu faço uma mistura dos dois.A única diferença é que nesse caso eu levo o português para mais camadas que você e não apenas na business.
Falando um pouco dessa mistura o que eu nunca traduzo é o nome dos patterns.Eu não crio uma classe chamada ClienteFabrica por exemplo, eu uso o nome da classe em português mais o nome do pattern em inglês, ficando ClienteFactory, pois quem conhece o pattern só de bater o olho já vai saber o que faz.
Tem funcionado bem usar dessa forma nos projeto que eu faço e na minha opinião o código fica bem expressivo.
CurtirCurtir
Legal, Roger
Eu evito ao máximo misturar as duas línguas em um mesmo nome (de classe, de método) e mesmo usar o nome do pattern no nome (principalmente em objetos de negócio), mas sempre há exceções e essa da Factory é uma delas.
Não vejo problema em “ClienteFactory”. Expressa bem é o que ele é e uma tradução irá comunicar pior e ficar ainda mais estranho.
Como disse, o código deve deixar o mais claro possível o seu propósito.
[]s
CurtirCurtir
Dado que a equipe tenha optado por codar em português, baseado nos pontos que tu levantou e que eu concrodo, quanto a parte de “onde escrever inglês e onde português” eu curto a ideia de escrever português em todas as layers, sem exceção. E apenas escrever em inglês termos técnicos que vão ajudar o desenvolvedor a sacar mais rápido o que aquela classe faz.
Exemplos: Acho FabricaDeUsuario menos claro do que UsuarioFactory. Já que “factory” é um termo conhecido tecnicamente e que facilmente identifica que essa classe é a implementação de um design pattern. Mais alguns exemplos nessa linha de “portugues misturado com ingles”: ContratoBuilder, PropostasController, CrarUsuarioCommand, CriacaoUsuarioHandler. Mas não é uma regra rígida, por exemplo, o termo “repositório” é bem comum ser chamado assim em português também, então pra esse cara eu aceitaria utilizar UsuarioRepositorio.
No final das contas, são convenções que devem ser decididas em conjunto com o time.
CurtirCurtir
Fora do domínio, a coisa toda é mais maleável (deve-se levar em consideração a clareza dos nomes). Como você mesmo exemplificou e como dito no artigo, fica muito dificil escrever 100% do código em portugues.
Alguns termos irão comunicar melhor em inglês, por serem relacionados a coisas técnicas (como algum “parser” ou “adapter” da vida). Mas não vejo problema em traduzir serviços técnicos se o nome em português (ou mesmo mesclado) passar a mensagem de forma clara.
Qto ao repositório, me acostumei em portugues, porque costumo implementar a interface (que fica no domínio) em portugues e ele recebe/devolve entidades com nome em portugues tb.
E mesmo no domínio, há uma mescla que acho aceitável (uma das raras exceções), que é o caso da factory que vc citou.
CurtirCurtir
Ótimo post, Robson. Sua opinião sobre isso é bem parecida com a minha. Infelizmente, tem muita gente que prega, de maneira quase religiosa, que apenas o inglês é aceitável. O que pode acabar causando os problemas que você citou no post.
Como você deixou bem claro, equilíbrio e bom senso é a chave. Um abraço!
CurtirCurtir
Valeu, Carlos
Tocou no ponto certo: muitos são bem religiosos mesmo (O inglês é o certo. Fim.). E muitas vezes , o “argumento” é “porque fica mais bonito” e não percebem todas as dores que vem disso.
[]s
CurtirCurtir
Essa é uma discussão boa. Eu já vi cada emaranhado divertido, tipo quando rola uns “populator”, “ajustator” e daí pra baixo.
A regra que eu sempre segui nos meus times é: definir onde é a “single source of truth” pra qualquer coisa do projeto. Minha opção número um, uma wiki. Logo, bota-se uma página lá chamada “coding standards”. Aí, na primeira trave que dá, senta com o time, discute qualquer convenção que faça sentido para aquele domínio/time/momento e documenta na Wiki.
Assim mantém-se a história pra quem é novo, o que não tá lá não tem padrão definido (logo, defina antes de seguir qualquer convenção pra não ter que mudar tudo) e daí pra frente siga o padrão.
Outro erro comum é tentar fazer todas essas definições antes de começar o projeto e perder umas boas semanas com discussões acaloradas sem entrega de software. Eu mesmo toda vez que vou contribuir com um projeto open source levo um puxão de orelha, geralmente por coisa super relevante como tab trocada por espaço ou espaço no final da linha (enquanto o código tem menos de 50% de cobertura por unit test quando tem alguma).
Então acho q convenção qualquer q seja, não tem certo e errado, tem aquilo que serve para o contexto.
Errado e não ter convenção e virar a casa da mãe Joana.
CurtirCurtir
Oi, Eric! Há qto tempo! 🙂
Pois é.. concordo contigo: deve haver convenções senão cada um faz do jeito que quer e acaba virando zona mesmo.
Eu acredito que, seja qual a convenção adotada, o código deve passar a mensagem da maneira mais clara possível e, em se tratando de operações de negócio, deve facilitar o entendimento das mesmas e a comunicação entre devs/negócio (e não jogar contra). E muitas vezes, programadores querem programar sempre em inglês (porque é “bonito”), esquecem desses pontos e o código vira aquele “inglês tupiniquim” que é uma beleza!
[]s e obrigado por comentar!
CurtirCurtir
Ótimo artigo Robson. Parabéns!
Onde trabalho temos boas discussões na utilização do idioma na exposição de APIs Públicas (contratos).
CurtirCurtir
Obrigado, camarada.
Deve ter muita treta!! :))
CurtirCurtir