Artigos, preposições, pronomes, verbos, entre várias outras classes de palavras, são características de vários idiomas ao redor do mundo. Cada uma delas desempenha um papel importante, e ficaria difícil montarmos orações sem uma delas, pois coisas básicas como determinar e conectar elementos, expressar ações, etc., são por elas especificadas, e que impõem suas regras de construção.
Quando estamos criando um software, é importante que se nomeie os seus membros de forma à expressar exatamente como temos no mundo real. Isso facilita muito durante o levantamento, desenvolvimento e, principalmente, na manutenção do código, permitindo que pessoas que não conheçam exatamente os detalhes de uma linguagem de programação, olharem para o código e entenderem o que está acontecendo ali. Justamente por isso é importante que você tente manter – também – durante a criação de classes, métodos, propriedades e variáveis, os mesmos elementos gramaticais que são utilizados no mundo real.
Em um artigo anterior eu já havia comentado sobre a utilização do idioma português ao invés do inglês. Se você está criando um código de infraestrutura, como por exemplo, um repositório de logs, classes que facilitam o acesso ao registry do Windows, etc., então você pode manter isso em inglês, pois fica até mais fácil encontrar nomes mais coerentes. Já quando estamos construindo as regras de negócio, onde vamos utilizar algum modelo para o desenvolvimento (DDD, TS ou AR), devemos sim utilizar o português e nos atentarmos para manter as classes de palavras do idioma, para expressar com exatidão o negócio no mundo virtual.
Ao criar variáveis, eu considero o uso das preposições como sendo extremamente importante para conectar uma parte da variável à outra. Se vamos criar uma váriavel que irá armazenar o nome do cliente, ao invés de utilizarmos nomeCliente, é muito mais intuitivo chamarmos de nomeDoCliente. Acredito que nomear a variável como nomeCliente acaba sendo uma má interpretação do inglês, por exemplo, se fossêmos criar a mesma variável em inglês, nomearíamos para customerName, mas lembre-se de que a tradução para customer name é nome do cliente. Para elencar mais alguns exemplos práticos:
DateTime dataDeNascimento = DateTime.Now;
decimal valorTotalDoPedido = 1000.00M;
decimal? taxaDeJuros = null;
bool permiteContinuarCasoEncontreFalhasNoProcessamento = true;
Action<decimal> calculoDeSalario = (salario) => { };
O mesmo vale para métodos. O que temos em mente é que métodos devem ser representados por verbos. Isso continua sendo válido, mas você deve nomeá-lo exatamente de acordo com a sua finalidade. Geralmente você utiliza o verbo em primeiro lugar e o restante complementa de acordo com a tarefa que ele desempenha, por exemplo:
RepositorioDeClientes repositorioDeClientes = new RepositorioDeClientes();
Cliente cliente = new Cliente();
cliente.Nome = “Israel Aece”;
cliente.Salario = 1000.00M;
this.CalcularLimiteDaContaCorrente(cliente);
repositorioDeClientes.Adicionar(cliente);
Depois do limite calculado, eu estou adicionando o cliente recém criado no repositório. Note que o método Adicionar é nomeado como Adicionar e não como AdicionarCliente. Como eu já estou em um repositório de clientes, eu já sei que ali eu só posso adicionar clientes. Não precisa “ratificar” isso no método. Além de desnecessário, complica a leitura.
Outro detalhe importante é quando você vai criar sobrecargas (overloads) de métodos. Na maioria destes casos, são os parâmetros (tipo e quantidade) que determinam a diferença entre as várias versões e não o nome, pois os nomes serão sempre os mesmos. Por exemplo, você tem uma classe que efetua a simulação de empréstimos pessoais, onde é necessário informar o valor a ser financiado e o CPF do cliente. Só que o cliente pode não estar com o CPF, mas tem ele na CNH ou no RG. Então você pode criar versões do método Simular, onde cada um utiliza um documento específico.
public class SimuladorDeEmprestimosPessoais
{
public void Simular(decimal valor, RG rg)
{
CPF cpf = ExtrairCPFDoRG(rg);
Simular(valor, cpf);
}
public void Simular(decimal valor, CNH cnh)
{
CPF cpf = ExtrairCPFDaCNH(cnh);
Simular(valor, cpf);
}
public void Simular(decimal valor, CPF cpf)
{
//efetua a simulação
}
}
Acima vemos um exemplo prático e expressivo, que olhando para os seus métodos, somos capazes de efetuar a simulação dado qualquer um dos documentos suportados (RG, CNH ou CPF) pela classe.
Como eu disse acima, com esse tipo de código é possível que pessoas que nem conheçam detalhes do C#, olhem para ele e consigam extrair e entender grande parte das funcionalidades que ele executa. Essa técnica tornará o seu trabalho e dos demais membros da equipe muito mais simples, principalmente quando precisamos efetuar algum tipo de manutenção em um código já escrito há algum tempo. A ideia é tentar praticar o que Martin Fowler já falou há algum tempo: “Any fool can write code that a computer can understand. Good programmers write code that humans can understand.”.
Israel Aece 
Bacana Israel.
Olha eu sempre tento nomear da melhor forma possível, já vou adotar aqui a dica do nomeDoCliente e não nomeCliente, realmente tem razão no que disse.
Parabéns mais uma vez.
Excelente post Israel.
Não consigo concordar com isso.
RepositorioDeClientes pra mim fica muito estranho de ler, por que você tem que passar por todo o "RepositorioDe" pra chegar no Clientes, enquanto que em inglês (CustomersRepository) fica tão mais fácil, pois o Customers já vem na frente, deixando logo bem claro de que contexto estamos falando.
Outra coisa que, normalmente, fica muito absurda neste tipo de prática, são os métodos "Eh" (Is), que retornam boolean. "EhValido", "EhImpar".
Não me leve a mal. Mas o inglês realmente nos dá uma legibilidade muito melhor. E, como a tendência é irmos para uma sintaxe cada vez mais declarativa, e menos imperativa, vai ficar muito estranho ter um código cada vez mais legível em inglês misturado com uma porção de termos em português.
Algo como:
var clientesElegiveis = from cliente in RepositorioDeClientes
where cliente.EhValido() && cliente.PossuiProduto(produto)
select cliente;
Não consigo achar isso elegante. Na verdade, parece tosco.
De qualquer forma, parabéns pelo blog.
Boas Daniel,
Eu também concordo com você quando menciona sobre o "Eh". Realmente é horrível e eu não adoto essa prática. E ainda, no teu exemplo "EhValido()", se tem o (), então é um método, ou seja, deve ser um verbo, e sendo assim, o "é" está descartado.
Já quando você compara o inglês ao português, da mesma forma você ainda menciona o "excesso" (que é Repositorio/Repository), a diferença é que você inverte a ordem, por questões gramaticais.
Por mais que você tenha um mix entre palavras em inglês (fornecidas pelas linguagens de programação) e palavras em português (as que você define para nomear os membros), eu ainda pago esse preço. Do meu ponto de vista, eu acho que é muito mais simples os desenvolvedores entenderem/descobrirem o significado de um comando do que o significado de um objeto de negócio.
E aí, Israel.
Só pra esclarecer, não é "excesso" o meu ponto. É a legibilidade.
Pra mim CustomersRespository é mais legível do que RepositorioDeClientes. Isso por que estamos falando de um exemplo simples. Não me incomoda o fato de haver uma descrição completa, ou seja, a palavra Respositorio não me incomoda, o que me incomoda é como ela prejudica a leitura.
Em inglês o contexto ganha mais força por que sempre vem na frente. Então você tem tudo mais a mão: CustomersRepository, SuppliersRepository, ProductsRepository. Enquanto que em português os 3 (e todos os outros) ficam mais misturados: RepositorioDeClientes, RepositorioDeFornecedores, RepositorioDeProdutos.
Não acho que deva haver uma definição do que é certo ou errado aqui. E digo isso somente para que não interprete meu comentário de forma negativa. Não acho que o Fowler tava dizendo a frase acima a respeito de usar a língua nativa. Até por que como desenvolvedores se não soubermos entender inglês estamos todos perdidos. Não li o livro em questão, mas não faz sentido alguém como ele ter falado isso nesse sentido, faria mais sentido se ele dissesse algo como evitar usar coisas como var1, var2, var3, flagx, flagy, flagz.
Sei lá. Concordo com a definição de método e, entenda, meu exemplo não se restringia ao que definimos ação ou estado. Se eu mudar o exemplo de "EhValido()" pra "EhValido" (de ação pra estado) ainda teríamos o mesmo problema: o "Eh".
Linguagens de programação não suportam os caracteres estrangeiros aos caracteres ingleses. E isso as torna limitadas a ponto de fazermos mal-uso da propria língua se quisermos aplica-la ao código.
Por fim, mais uma vez, parabéns pelo blog.
Boas Daniel,
Brother, seus comentários são sempre bem-vindos. Eu fico agradecido por comentar por aqui!
No comentário do MF, eu interpretei dessa forma, seja em inglês ou português, escrever código que um humano saiba ler, é justamente evitar "criptografar" os nomes das variáveis, métodos, classes, etc, e além disso, tornar o código coerente, que ao ler, reflete exatamente o que acontece no mundo real, com seus respectivos elementos.
Ainda sim, não estou convencido de que o inglês seria a melhor alternativa (exceto para código de infraestrutura). O que eu acho Daniel, é que ele válido se o projeto tem um escopo global, do contrário, acredito que possa ser utilizado o idioma local. Particularmente eu tenho utilizado isso nas aplicações que tenho desenvolvido, e com sucesso. A finalidade do post foi tentar mostrar uma possibilidade de nomenclatura portuguesa para membros do software, e tentando utilizá-la de forma mais apropriada, evitando essas estranhezas ("Eh"). No teu exemplo, em minha aplicação eu faço:
public bool EstaValido
{
get
{
return this.Validar();
}
}
Cliente cliente = new Cliente(…);
if (cliente.EstaValido)
{
new RepositorioDeClientes().Adicionar(cliente);
}
Se você se sente mais a vontade para nomear em inglês, então acho válido você utilizá-lo. Algumas vezes onde tentei fazer isso em alguns projetos, o significado para alguns elementos do negócio não soavam tão bem e intuitivo como no português.
Concordo com o Daniel Moreira, acho que a questão do Repository, é que ele é um padrão assim como Request/Response (Que seria traduzido como Solicitação/Resposta ou similar).
Onde eu trabalho definimos que tudo que são padrões/tecnologia manteremos os nomes originais, já os métodos e variáveis e métodos devem ter uma nomenclatura bem coerente e realmente expressar sua função.
Mas, na minha opinião, acho que tudo deve ser feito em inglês, já que isso é o requisito mais básico para aqueles que exercem a profissão de TI.
Só para complementar, um ótimo e curto artigo de Jeff Atwood some nomeclatura de membros.
http://www.codinghorror.com/blog/2006/03/i-shall-call-it-somethingmanager.html
Sou a favor da nomenclatura em português pelos seguintes motivos, meus:
– Dificilmente a equipe inteira é qualificada o suficiente pra escrever corretamente em inglês. Ou seja, os métodos e variáveis 60% das vezes estão escritos de forma errada.
– Dificilmente a equipe inteira é qualificada o suficiente pra ler um inglês menos técnico, caso o projeto seja menos "convencional". Ou seja, há uma dificuldade em entender o propósito do método/variável com facilidade para essas pessoas nesses casos.
– Dificilmente encontro programadores que dominem o próprio idioma. Ou seja, se o caboclo fala "pra mim programar" ou escreve "//abre conecção" (sim, já li isso!!!!), duvido muito que o mesmo tenha uma boa escrita em inglês.
Entendo pouco de inglês mas não peco em nada em termos de desenvolvimento. O que me deixa puto é nego que está bem aquém do conhecimento que eu tenho de inglês, que é pouco, querer pagar de "programador-robo-teoria-boas-praticas" escrevendo tudo errado em inglês e defender seus propósitos. E isso é o que eu mais vejo por aí. Nesses casos, opto pela nomenclatura em português.
Bom artigo e bela discussão nos comentários!