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).

Era isso! (Concorda? Vê pontos contrários? Comente aí!)