//Exemplo:
olor:#ffffff;">}
52. O event handler não deve conter código para executar uma ação
Eventos servem para disparar chamadas a objetivos e não para deixar todo o objetivo, ou seja, a lógica no evento. Isto acabará com o reaproveitamento de código, pois mais de um evento pode chamar o mesmo método.
Considere invocar um método que execute o que você deseja no evento.
53.
Execução de eventos pré-programados
Não execute programaticamente a ação de click de um botão que já esteja disponível no evento click. Ao invés disto invoque o mesmo método que seria invocado pelo evento do clique.
54.
Evite arquivos muito grandes.
Se um arquivo possuir mais de 1000 linhas de código este com certeza é um grande candidato a refatoramento e com isto pode ser dividido em mais de um arquivo, o que geralmente significa mais de uma classe.
55.
Evite linhas de código com muitas funções.
Esta prática não denota conhecimento de código complexo e ainda torna o código difícil de ler, atualizar, efetuar manutenção ou mesmo de detectar erros.
//Ex:
return
int
resultado = Convert.toInt32(GetResult(variavel), fatorPonderacao);
Aqui vemos um retorno de uma variável que será inicializada e populada pelo retorno de um método o qual ainda precisa de dois parâmetros, e por fim precisa ser convertido para o tipo de dados. Um erro ocorrendo nesta linha
pode ser provocado por diversos motivos. Considere separar a lógica para se tornar mais clara.
56.
Não escreva mais de uma classe por arquivo
Salvo os raros momentos em que este uso é justificado evite criar mais de uma classe por arquivo. Na dúvida separe uma classe por arquivo.
57.
Evite métodos e propriedades públicas
A não ser que seja estritamente necessário expô-las. Utilize internal caso o método ou propriedade deve ser acessível, porém apenas dentro do mesmo namespace.
58.
Evite passar muitos parâmetros para um método.
Se você possui um método que recebe mais de 4 parâmetros, tais parâmetros são fortes candidatos a se tornarem uma classe ou uma struct.
59.
Organize logicamente seus arquivos/classes na Solution dentro de pastas.
Normalmente em grandes projetos podemos chegar a 10 pastas principais com até 10 pastas secundárias, e até 5 pastas terciárias. Se for necessário criar mais folders, considere criar outro namespace para isto.
60.
Crie classes organizadas que possam exibir logs de acordo com configurações.
Sua classe idealmente deve ser capaz de obedecer a configuração do log. Por exemplo, se a configuração de log está marcada para
error, você logará apenas mensagens de erro. Já se estiver marcada para
trace, você logará todas as mensagens errors,
warning ou traces.
61.
Feche conexões abertas antes de sair do método.
Salvo alguma lógica que necessite manter a conexão aberta, se você está abrindo conexões com bancos de dados, sockets, file streams, etc sempre as feche no bloco finally.
62.
Sempre utilize arquitetura multi-camandas
Trabalhe sempre com arquitetura de 3 ou mais camadas para garantir o devido isolamento
de acessos e responsabilidade.
63.
Nunca acesse uma base de dados a partir de páginas UI.
Esta prática vai de oposto a programação em multi-camadas e é extremamente condenável.
64.
Preencha o aquivo AssemblyInfo
O Arquivo AssemblyInfo é importante para sistemas de longa média ou longa vida útil, além de ser uma boa prática manter as informações como versão, nome da empresa, descrição, copyright, etc.
65.
Apresente uma mensagem de erro amigável
Usuários não gostam e nem estão preparados para mensagens de erros complexas. Porém é recomendado que a tela de erro apresente também a mensagem de erro técnica, ou que esta esteja disponível em arquivos de Log.
O recomendado é que as duas ações sejam efetuadas.
66.
Utilize try-catch em sua camada de dados
Em exceções de banco de dados o handler desta exceção deve gravar todas as exceções de base de dados, e o nível de detalhes deve incluir qual comando ou procedure foi executado, com quais parâmetros, conexão utilizada e etc.
67.
Não grave objetos muito grandes em sessão.
Isto pode>
O recomendado é que as duas ações sejam efetuadas.
66.
68.
Sempre utilize uma folha de estilos para controlar a aparência de suas páginas.
Nunca especifique tamanho de fonte, cor, etc diretamente em uma página web. A manutenção de um sistema desta forma é muito complexa e fadada a erros.
69.
Ao inicializar uma variável com um número especial deixe muito claro as razões.
Magic Numbers são na maioria das vezes evitáveis. Desta forma, caso você precise criar um
magic number e este não possa ser configurável, deixe muito claro quais foram as razões de ter utilizado esta prática pouco ortodoxa.
70.
Nunca crie um “Catch pelado”, ou seja, um catch que não faça nada.
Se você esconder a exceção você nunca vai sabe quando ou se algo errado ocorreu. Você estará indo contra si mesmo.
71.
Antes de capturar exceções genéricas tenha certeza que cobriu as exceções específicas.
E se necessário crie exceções específicas para sua necessidade. Mas verifique se há a necessidade de haver uma exceção específica criada ou se é mais uma vontade. Exceções criadas geram maior atenção na criação e na manutenção.
72.
Não capture e trate as exceções em todos os seus métodos.
Deixe a responsabilidade com a camada mais alta que chamou o método. Exceto para casos específicos como exceções de banco de dados.
73.
Quando você for disparar uma exceção para a camada ou método chamador, utilize
throw sem nenhuma variável inclusa
Desta forma o call stack original será preservado para o devido tratamento.
74.
Não crie try-catch para 100% de seus métodos.
Coloque try-catch apenas onde há a possibilidade de ocorrer um erro.
75.
Não crie blocos try-catch muito grandes.
Se necessário crie blocos separados de try-catch de acordo com o grupo de funcionalidade que está trabalhando. Assim o tratamento do erro será mais assertivo e a manutenção mais simples.
76.
Se for criar exceções próprias herde de ApplicationException.
Muitos programadores quando criam exceções próprias herdam de SystemException. Mantenha o escopo mais próximo herdando de ApplicationException.
77.
Mensagens de erro existem para ajudar a resolver um problema;
Tendo este pensamento em mente não retorne mensagens como: "Erro na aplicação", "Ocorreu um erro", etc.
Forneça dados específicos e tratados do erro para que o mesmo possa ser resolvido mais rapidamente. Ex.: "Falha de autenticação ao se comunicar com o Banco de dados, por favor, forneça o usuário e senha corretos".
78.
Na inicialização de uma aplicação faça um auto-diagnóstico.
Para garantir que todas as dependências requeridas estão disponíveis, sejam arquivos, acessos, bancos de dados etc. Esta é uma excelente prática, pois mesmo quando o sistema estiver em produção será mais fácil identificar algum
problema de dependência sistêmica.
Forneça dados específicos e tratados do erro para que o mesmo possa ser resolvido mais rapidamente. Ex.: "Falha de autenticação ao se comunicar com o Banco de dados, por favor, forneça o usuário e senha corretos".
78.
Na inicialização de uma aplicação faça um auto-diagnóstico.