sexta-feira, 21 de março de 2008

O nome é importante

Podemos até achar que não, mas o nome é importante. Desde comprimentar aquela pessoa que encontramos frequentemente falando seu nome até definir O nome para o que desenvolvemos.

O Básico


Quando vamos programar, ainda mais no começo de nossa vida de desenvolvedor, podemos estar tão ansiosos em utilizar a coleção genérica, ou o LINQ que acabamos de aprender, que esquecemos de dar importância a alguns pontos básicos. Dentre os que podem ser deixados para traz, está o nome do que escrevemos.

Para enfatizar isto ainda mais, uma das características de um código bem escrito é ser fácil de entender. Se expressamos nossa idéia, por exemplo escrevendo um método, e ninguém o entende. Ou somos muito inteligentes ou achamos que somos muito inteligentes. A tendência é cairmos no segundo caso. Uma das coisas mais importantes de um método é seu nome.

A idéia é que com um nome consigamos:
• Deixar suficientemente explicativo ao ler
• Definir de forma clara a competência do método(O que ele faz e o que não faz)
• Ser consistente

Antigamente, algumas linguagens tinham limites de tamanho para nomes. Vamos supor que nós tivessemos 8 caracteres para definir nomes, realmente isto seria um dificultador. Por exemplo, se eu desejar criar um método que retorne a data de vencimento da última prestação de um financiamento, teria certa dificuldade:

public DateTime GeVeUlPr

Hoje em dia, linguagens modernas como o C#, permitem escrever nomes com certa liberdade. No caso do C#, estes nomes não podem ser maiores que 512 caracteres(Você já precisou de mais?). Poderíamos então usar o nome assim:

public DateTime GetVencimentoUltimaPrestacao

Tendo um nome bem definido nos ajuda a achar este método para uma posterior reutilização, e principalmente no momento de escrever seu corpo, estaríamos direcionados a resolver o problema a que ele se propõe, nada mais e nada a menos.

Se você ainda não está convencido, imagine que neste sistema de financiamento tenhamos estas variáveis

DateTime DtVen;
DateTime DtPag;
DateTime DtCan;
DateTime DtJur;
Decimal Val;
Decimal JurDi;
Decimal ValCJur;
Bool ParAtr;

Você sabe intuir sobre o que elas armazenam? Talvez sim, mas escrevendo da forma abaixo, seria no mínimo mais fácil imaginar o que elas armazenam:
DateTime DataVencimento;
DateTime DataPagamento;
DateTime DataCancelamento;
DateTime DataJuros;
Decimal Valor;
Decimal JurosDiario;
Decimal ValorComJuros;
Bool ParcelaAtrasada.

Para finalizar, é importante o parâmetro ser consistente, quero dizer que se eu criei a variável acima ParcelaAtrasada, eu não poderia reutilizá-la para outra coisa, por exemplo para armazenar que a parcela foi paga. Depois de alguns dias, nem você lembraria disso. É interessante criarmos outra variável para isso, ou até pensar em armazenar estas informações de outra forma, quem sabe um enumerado?

Com esta idéia de bom senso acima, já estaremos muito bem encaminhados para um código bem escrito, mas existe algo a mais...

Referência:
(Caso alguém tenha sugestão de alguma referência, de algum livro que trate do tema acima, ficarei grato para me embasar não somente em experiência)

Naming Convention


A convenção para nomeação é utilizar padrões para nomear o que se desenvolve, esta parte talvez seja mais metódica, mas faz sentido. Como o C# é uma linguagem Case Sensitive, escrever com o padrão ajuda a achar e utilizar toda a Framework .net. Não seria interessante seguir o padrão e ter a mesma facilidade para achar o nosso código?

Abaixo segue alguns links sobre a convenção de nomes utilizada pela microsoft:
http://msdn2.microsoft.com/en-us/library/xzf533w0(VS.71).aspx
http://msdn2.microsoft.com/en-us/library/ta31s3bc(VS.71).aspx

Liberando o fonte


Condificamos, testamos e está funcionando. Agora é só ficar livre disto e acabou, certo? Claro que não, agora é a hora de revermos o que acabamos de escrever. Não muito diferente da escola, quando revíamos o texto para entregar para professora. Não gostava da professora? Tudo bem, é a mesma coisa de rever a carta da surpresa para a namorada. Nunca releu? Nem no dia dos namorados?

Nos limitando a resolver nosso código, a idéia é rever o texto, ver se os métodos estão bem definidos, bons nomes e atuar no sentido de deixar o código ainda mais claro. Pense que você quem pode dar manutenção nisso daqui a alguns meses e poderá se orgulhar ou não do que encontrar. E temos até ferramenta para nos ajudar no trabalho manual, podemos usar um recurso do Visual Studio que é o Refactor.

O Refactor


Escreveu um nome e não gostou? Quer mudar? O Visual Studio nos ajuda, use o refactor:
http://msdn2.microsoft.com/en-us/library/ms379618(VS.80).aspx