Reflection No Dia a Dia – Parte 01

Geralmente quando falamos de Reflection pensamos em códigos sendo gerados em runtime, carregar uma dll dinamicamente e coisas que assustam, mas por outro lado podemos usar reflection para coisas bem menos complexas, porém muito uteis.

Por exemplo no código abaixo uso reflection para pegar o nome do método onde a exception foi gerada.

Utilizo o getype().tostring para pegar o nome do objeto e com  MethodBase.GetCurrentMethod().Name pego o nome do método , assim logo o nome da classe e do método onde o erro ocorreu, poderia estar logando o tempo de execução do método.
…..
catch (Exception ex) {
               
                retorno = false;

                System.Diagnostics.Trace.WriteLine(this.GetType().ToString() + " – " + System.Reflection.MethodBase.GetCurrentMethod().Name + "[" + ex.Message + "]");
           
            }

Para uma visão geral dos recursos da utilização de Reflection sugiro os links : http://www.linhadecodigo.com.br/ArtigoImpressao.aspx?id=264
e http://iamacamera.org/default.aspx?section=home&id=58

Comparação de Texto (String)

Embora seja uma das tarefas mais triviais da programação a comparação entre strings costuma gerar muito bugs nos sistema por um simples detalhe.
No .Net assim como na maioria das linguagens de programação por padrão a comparação de string é case sensitive, com isso temos erros como

var1 = "teste";
var2 = "Teste";

if (var1 == var2)
//aos olhos do programador inexperiente o código deveria executar essa parte
else
// mas como a comparacao é case sensitive o bloco executado será esse

/////////////////////// Para corrigir esse pequeno Bug devemos usar o código abaixo //////////////////////////////////
if (var1.Equals(var2, StringComparison.OrdinalIgnoreCase))
  // Agora sim esse código sera executado
else
 //E esse sera ignorado

Outra forma  de evitar esse erro seria usar a função ToLower (caixa baixa) ou  ToUpper (caixa baixa) para que ambos as variaveis fiquem com a mesma caixa.

Links de referência:
http://msdn.microsoft.com/en-us/library/system.stringcomparison.aspx

http://msdn.microsoft.com/en-us/library/ms973919.aspx

Padrão para Métodos – Part 1

Muito ja li sobre padrões de como os métodos devem ser feitos , ja vi muito código de outros programadores e também os meus códigos antigos, com base nessa experiência vou listar os pontos positivos e negativos que ja vi nesses quase 10 anos de profissão:
 
Métodos com mais de 100 linhas, porque:

Nunca Faça
    • Nem você vai entender o código direito depois de duas semanas
    • Dificil entendimento , terrível para dar manutenção
    • Mais dificil de evoluir
    • Está fazendo mais do que o nome do método Diz …

Tente Fazer

    • Métodos que possam ser lidos na resolução de 1024  sem precisar de scroll
    • Crie métodos auxiliares para decompor o código, assim fica facil de melhorar e debugar problemas
    • O código do método deve fazer o que o nome sugere assim o código fica de facil entendimento , ficando quase auto documentado

Métodos com 30 parametros
Nunca Faça

  • Fica complicado  de ver todos os parametros. Provavelmente você esteja fugindo da orientação a objeto
  • Fica facil inverter a ordem de algum valor e daí haja debug para achar o erro

Tente Fazer

  • Procure criar objetos e passar os objetos para o método ou trabalhar com propriedades

 

Duplicação de código Ctrl + C , Ctr + V

Nunca Faça

  • Código duplicado significa dois lugares para corrigir e/ou melhorar
  • Torna o código mais extenso do que o necessário
  • Aumenta em muito as chances de bug na aplicação, pois qualquer alteração tem que mapear os lugares onde o código esta duplicado

Tente Fazer

  • Quando precisar de uma funcionalidade que esta embutida em algum método, extraia a mesma para um método separado
  • Métodos com poucas linhas tendem a ser reutilizados, pois são bem especializados numa tarefa

 

Regra de Negócio  utilizando exception

Nunca Faça

  • Utilizar exception para regra de negócio degrada a performance
  • Falta de planjemanento

Tente Fazer

  • Trabalhe com o envio de mensagens
  • Planeje a troca de mensagens, para facilitar tanto a camada de negócios como a interface da aplicação

 

 

 

Convert.ToString/(String) X objeto.ToString


Embora o uso do ToString  seja  bem comodo para nós , acaba nos trazendo uma dor de cabeça desnecessária, pois para usar o ToString temos que garantir que  o valor não seja um nulo ou o famoso dbnull , senão uma exception nos aguarda.

Poucos sabem que existe uma maneira simples de corrigir isso que é utilizando o Convert.toString , no código abaixo se executado vocês poderam ver que o erro de conversão só ocorre na linha do tostring …

 

Dim teste As Object = Nothing

Dim teste2 As String

teste2 = Convert.ToString(teste)

teste2 = teste.ToString()

.Net Usando TryParse

Na versão 1.1 do .Net  não tinhamos uma maneira de checar se um valor era numerico do tipo Int , usando as classes de compatilibilidade do vb tinhamos a famosa função isnumeric , mas um isnumeric = true não significava isInt =true . A versão 2.0 do .Net trouxe o método Tryparse que recebe como parametro um valor e uma variavel  , se o valor for compativel ele retorna true e seta o valor da variavel , senão ele retorna false.
 
O código abaixo irá retornar  true para a variavel valor3 e 200 para variavel valor2:
 

Dim valor As String = "200"

Dim valor2 As Integer

Dim valor3 As Boolean

valor3 =

Integer.TryParse(valor, valor2)

Podemos utilizar esse método para validar data , assim como validar um endereço de IP. O código abaixo ira validar se  o valor é um ip válido.

 

Dim

ip1 As String = "200.200.1.2"

Dim valor4 As Boolean

Dim ip As System.Net.IPAddress

valor4 = System.Net.IPAddress.TryParse(ip1, ip)

 

Então agora na versão 2.0 não tem mais desculpa para utilizarmos a geração de exception para esses casos, o que deve ser sempre ser evitado…. pois como o nome mesmo diz exception  deve ser uma excessão …  … e não um fluxo nomal do seu código.