Meus príncipios para developer software em .NET

07 Jul 2019, CSHARP

1019 Palavras, por José luiz

#Regras , #Convenções , #Ambiente



Intro

Fala Deve, tudo certo hoje? Então, hoje vou compartilhar com vocês minhas regras pessoais para desenvolvimento de software, mas não vou falar de SOLID não, ou ACID isso fica para outro post.

O que eu quero compartilhar é as regras, ou melhor dizendo príncipios que eu fielmente sigo quando vou desenvolver algum software, em especial usando framework .NET

Eu acredito fortamente que você também deveria seguir alguns, se não todos.

Estes princípios eu criei após 9 anos desenvolvendo software e revisando códigos. Eu sei, isso pode ser pessoal, mas enfim.. acho válido compartilhar….


Meus Princípios

Ahhh os princípios não estão priorizadas, apenas numeradas.

  1. Convenções para nomes
  2. Evite Regions
  3. Use Exception para Erros
  4. Evite parâmetros boleano
  5. Evite muitos parâmetros
  6. Warning como erros
  7. Encapsulate Expressões Complexas
  8. Tente evitar multiplas saídas diretas
  9. Mantenha seu métodos pequeno
  10. Mantenha suas classes pequena
  11. Prefira Interfaces a Abstract Class

#1 Convenções para nomes


Parece óbvio, mas o que eu vejo de “strEdit” ou “edt_nome”… Velhos desenvolvedores sempre discutem sobre nomenclatura de nomes de variáveis, classes, métodos… Na minha opinião basta seguir este Guidelines lá tem todas as diretrizes necessárias para usar.

Mas basicamente:


O que eu realmente não gosto e não faço!

  1. Nomear campos com iniciais que referenciam o tipo (strNome, str_nome)
  2. Nomear elementos com o tipo do elemento (edtNome)
  3. Variaveis com nome sem sentido, exceto para loop!
  4. Classes com nome sem sentido
  5. Falta de coerencia no padrão! Se começar com “str” por exemplo, por alguma política, faça-o até o fim!

#2 Evite Regions


Como assim!, Jose você está louco! Regions são usado para facilitar a navegação em uma class grande, e ai está o problema! Se um arquivo é grande o bastante para ter que organizar com regions talvez o problema esteja no seu código. Se você tem uma classe onde precisa usar regions para se encontrar lá… talvez um pouco de OOP resolva

Mas a verdade é que eles existem apenas para esconder códigos, ponto final.

   class Customer
   {
      #region CustomerManager
      ...
      #endregion
      #region CustomerRole
      ...
      #endregion
      #region CustomerAccess
      ...
      #endregion
      #region CustomerMethods
      ...
      #endregion
   }

#3 Use Exception para Erros


Em métodos booleanos, use Exceptions para tratamento de erro, isso permite estender e entender o que realmente está acontecendo. Existem certos momentos que o fluxo é mais indicado, Exception deve ser usado para indicar um erro no programa.

No código abaixo provalemente o erro estaria na chamada por permitir name nulo, mas o fato é que o método retorna false e na verdade deveria ser uma Argument Exception.

   public bool CheckCustomer(string name)
   {
       if (string.IsNullOrEmpty(name))
       {
         return false; 
       }
       ...
       return true;
   }

#4 Evite parâmetros boleanos


Evite parâmetros boleanos, Você pode ter sobrecarga de métodos para este fim, ou usar até mesmo interfaces para mudar comportamento de métodos, mas usar parametros boleanos é uma péssima idéia, nunca se sabe o que de fato o parâmetro foi criado, veja no exmeplo: O que o parâmetro faz?

Se você se depara com o código abaixo para analisar, o que o segundo parâmetro faz? Fecha a conexão? Fecha o arquivo?

   storage.Write(data, false);

Só vai saber se ir até o método!

   public void Write(string file, bool flush)
   {
       // ...
       
   }

Você poderia criar métodos para isso, veja os modificadores de acesso!

   public void WriteAndFlush(string file)
   {
       Write(file, true)
       
   }

   public void Write(string file)
   {
       Write(file, false)
       
   }


   private void Write(string file, bool flush)
   {
       // ...
       
   }

#5 Evite muitos parâmetros


Muitos paramentos no métodos fazem perguntar qual a relação entre os parâmetros? Gosto de ver até 3 parâmetros, 4 em casos extremamentes específicos. (use uma classe no parametro!)

Evite:

   public void Login(string username, string password, bool persist, string ipAddress, IUser user, IUserServices services)
   {
       // ... 
       
   }

O que poderia ser feito:

   public void Login(ILoginUser user)
   {
       // ... 
       
   }

#6 Warning como erros

Configure seu BUILD para ver warning como erros. Lembre-se que Warnings vão deixar seu código sujo e difícil de manter e testar!

Se estiver usando Visual Studio, abra as configurações do editor e altere as configurações no build, se estiver usando o Visual Studio Code, basta abrir o arquivo .csproj e adicionar a tag abaixo:

  <PropertyGroup>
    <TreatWarningsAsErrors>true</TreatWarningsAsErrors>
  </PropertyGroup>

Pronto, agora seus warning serão tratados como Erros.

#7 Encapsulate Expressões Complexas:

Se você tem uma expressão complexa verifique se ela não pode se tornar um Método dentro da Classe!

Evite:

  
   if(login.Try > totalAllow && !login.IsVip && login.DueDate > CurrentDate)
   {
     // ..
   }

O que poderia ser feito:

   if(login.IsAllowToAccess)
   {
     // ..
   }

#8 Tente evitar multiplas saídas diretas

Em métodos boleanos tente evitar muitas saida de forma direta.

Evite:

  
   if(Account > 0)
   {
     return false;
   }
   else if (IsVip)
   {
     return false;
   }
   else if (Account < 10)
   {
     return false;

   }
   else if (PastDue)
   {
     return false;

   }

   return true;

É melhor criar uma varável para isso

   bool isValid;
  
   if(Account > 0)
   {
     isValid = false;
   }
   else if (IsVip)
   {
     isValid = false;
   }
   else if (Account < 10)
   {
     isValid = false;

   }
   else if (PastDue)
   {
     isValid = false;

   }

   return tisValid;

#9 Mantenha seu métodos pequenos

Dev, isso é primordial, mantenha seus métodos pequenos! se precisar crie outro métodos com nomes bem sugestivos para evitar também comentários! , mas métodos deveriam ser pequenos o máximo que possível.

#10 Mantenha suas classes pequenas

Outra parada importante! mantenha suas classes pequenas, Use abstract, interfaces, Delegates.. Claro que a pergunta aqui é “O quanto é pequeno?”

Pequeno o bastante para que alguém possa entender facilmente! simples assim.

#11 Prefira Interfaces a Classes Abstract

Eu sei que vai depender do contexto, o que eu quero dizer aqui é ao fato que muitos developers abusam tanto de classes abstratas que o código fica ilegível além de pouco funcional, lembra que o C# não aceita multiplos heranças de classes né?

Conclusão

Construir aplicações não significa apenas focar no objetivo final, mas sim em preocupar-se com o código e como ele será mantido, acredite!

E ai faz sentido para você ?

Cansei de pegar projeto ou re-escrever projetos por conta de má criação de código, eu sei por que eu já fui assim!

Vamos praticar o bem dentro dos código, beleza?

Note...

Olá, meu nome é José Luiz e você sabe meu compromisso com você - sem post pagos, sem anuncios, sem conteúdo privado, somente post.

Se você curtiu esta produção, por favor, considere me enviar um cafézinho para apoiar o que eu faço...

Me pague um café e ajude o mundo!

Toda contribuição é enviada para MSF & O Bem nunca para :)