SQL Server - Remover tab – line feed – carriage return

REPLACE(REPLACE(REPLACE([TextField], CHAR(9), ”), CHAR(10), ”), CHAR(13), ”)

Resumo do livro Clean Code

Resumo de alguns tópicos do livro Clean Code do Uncle Bob, recomendadíssimo!

programador profissional é aquele que produz código limpo e testado!

 Regra de escoteiro: “você deve sempre deixar o lugar mais limpo do que encontrou” 

Nomes significativos

Nomes de classes, variáveis, métodos, etc, devem ser significativos, indicando claramente o que um método faz ou o que um atributo representa. A intenção deve ser visível através dos nomes. Crie nomes pronunciáveis para facilitar a comunicação, evite acrônimos e siglas.

Evite nomes confusos, os quais podem levar quem lê o código a conclusões erradas.

Use nomes que refletem o domínio do sistema, o contexto e os problemas que devem ser resolvidos.

Funções

Funções devem ser pequenas. Aliás, elas devem ser ainda menores. Deve haver apenas um nível de abstração por função.

Funções devem fazer uma coisa, e apenas uma. Novamente, utilize um nome que descreva bem o que a função faz. Utilize o menor número de argumentos possível, fazendo o máximo para que não passem de três.

Cuidado com “efeitos colaterais”, funções não podem fazer nada “escondido”. Use exceções ao invés de códigos de erro, e considere que tratar exceções é uma coisa.

Comentários

Comentários não salvam um código ruim. Procure explicar o que o código faz COM CÓDIGO.

Crie nomes de métodos e de variáveis informativos, ao invés de explicar com um comentário o que um método com um nome ruim faz. Use comentários para deixar uma expressão complexa mais clara, para avisar sobre as possíveis conseqüências de uma alteração, ou para ressaltar a importância de certo ponto do código.

Comentários ruins também poluem o código. Não escreva comentários redundantes, inúteis, ou pior, com falsas informações. Também não deve ser usado para indicar quando ou por quem foi alterado, para isso temos ferramentas de controle de versão. Não escreva comentários confusos ou grandes demais.

Não comente código que não será mais usado, simplesmente remova-o.

Objetos e estruturas de dados

Siga a Lei de Demeter. Faça boa abstração e encapsulamento. Não crie objetos burros.

Tratamento de erro

Use exceções ao invés de códigos de erro. Use exceções não checadas, e utilize mensagens de erro informativas.

Não retorne e nem passe null.

Testes

Siga as 3 leis do TDD.

Use uma assertiva por teste, e teste um conceito por vez.

Os testes devem ser rápidos, independentes, reprodutíveis em qualquer ambiente, auto-validáveis e escritos no momento certo. Mantenha o código de seus testes limpo.

Classes

Classes devem ser pequenas e seguir o princípio da responsabilidade única. Devem ser coesas,  essa coesão resulta em classes pequenas. Classes devem ser criadas visando a mudança, então programe orientado à interface.

Outros pontos que não posso deixar de citar são: Todos os testes devem estar passando; refatoração deve ser feita constantemente, visando à melhoria contínua; código duplicado deve ser evitado a todo custo; classes e métodos devem ser pequenos; o código deve ser o mais expressivo possível.

Esse resumo é um levantamento de alguns pontos importantes, tanto que aqui é mostrado o que deve ser feito, não o porquê ou o como, isso pode ser encontrado no livro. Esse post é o primeiro passo, espero que todos dêem continuidade lendo esse livro e muitos outros, buscando criar um código melhor. Eu não quero mais código sujo atrapalhando a minha vida. E você?

(Resumo feito  por Juliano Alves)