Clean Code - Guia e Exemplos

ndice

• ndice
• O que o Clean Code?
• Regras gerais
  • Siga as convenes
  • KISS
  • Regra do escoteiro
  • Causa raiz
• Regras de design
  • Mantenha dados de configurao em alto nvel
  • Exemplo
  • Polimorfismo no lugar de IFs
  • Exemplo
  • Mult-thread
  • Exemplo
  • Separe os cdigos mult-thread
  • Exemplo
  • Utilize Async como sufixo
  • Evite configuraes desnecessrias
  • Exemplo
  • Utilize injeo de dependncia
  • Exemplo
  • Lei de Demeter
  • Exemplo
• Regras sobre entendimento do cdigo
  • Seja consistente
  • Exemplo
  • Utilize variveis concisas
  • Exemplo
  • Obsesso primitiva
  • Exemplo
  • Evite dependncias lgicas
  • Exemplo
  • Evite condicionais negativas
  • Exemplo
• Regras de nomes
  • Escolha nomes descritivos
  • Exemplo
  • Faa distines significantes
  • Exemplo
  • Utilize nomes pronunciveis e buscveis
  • Exemplo
  • Evite uso excessivo de strings
  • Exemplo
  • No use prefixo ou caracteres especiais
  • Exemplo
• Regras para funes ou mtodos
  • Pequenas e com apenas um objetivo
  • Exemplo
  • Utilize nomes descritivos
  • Exemplo
  • Opte por poucos parmetros
  • Exemplo
  • Cuidado com efeitos colaterais
  • Exemplo
  • No tome decises desnecessrias
  • Exemplo
• Regras de comentrios
  • Um cdigo bom expressivo
  • No seja redundante
  • Exemplo
  • No feche os comentrios
  • Exemplo
  • Evite cdigos comentados
  • Exemplo
  • Inteo
  • Exemplo
  • Esclarecimento
  • Exemplo
  • Consequncias
  • Exemplo
• Estrutura do cdigo
  • Separe conceitos verticalmente
  • Exemplo
  • Declare variveis prximas de seu uso
  • Exemplo
  • Agrupe funcionalidades similares
  • Exemplo
  • Declare funes de cima para baixo
  • Exemplo
  • Mantenha poucas e curtas linhas
  • Exemplo
  • No use alinhamento horizontal
  • Exemplo
  • Use os espaos em branco corretamente
  • Exemplo
  • No quebre a identao
  • Exemplo
• Objetos e estruturas
  • Esconda estruturas internas
  • Exemplo
  • Opte por estrutura de dados
  • Exemplo
  • Evite usar dados e objetos juntos
  • Instanciar poucas variveis
  • Exemplo
  • Classe base no deve saber sobre suas derivadas
  • Exemplo
  • Mais mtodos, menos tomadas de deciso
  • Exemplo
  • Evite mtodos estticos
• Testes
  • Um assert por teste
  • Legvel
  • Exemplo
  • Rpido
  • Exemplo
  • Independentes
  • Exemplo
  • Repetitvel
  • Exemplo
• Code smells
  • Rigidez
  • Fragilidade
  • Imobilidade
  • Complexidade desnecessria
  • Repetio desnecessria
  • Opacidade
• Fontes

O que o Clean Code?

Por que estamos falando tanto sobre cdigo limpo (Clean Code) e por que isto to importante para ns? De fato a manuteno de um software to importante quanto sua construo.

Como relatado por Robert C. Martin em seu livro clssico, Clean Code, um Best Seller da nossa rea, algumas prticas e vises so importantssimas para mantermos a vida do nosso software.

IMPORTANTE Este artigo no descarta a leitura do livro, que muito mais denso e profundo sobre o assunto.

As empresas investem milhes em softwares todo ano, mas com tantas mudanas no time e nas tecnologias, como fazer este investimento durar? Como garantir uma boa manuteno, durabilidade, vida ao software? Segundo Uncle Bob, as prticas abaixo so o caminho.

Regras gerais

Siga as convenes

Se voc comeou agora em um projeto ou acabaram de definir suas convenes, siga-as! Se utilizam por exemplo constantes em maisculo, enumeradores com E como prefixo, no importa! Siga sempre os padres do projeto.

KISS

Mantenha as coisas simples! Este conceito vem at de outro livro, e particularmente acho que a base de uma boa soluo. Normalmente tendemos a complicar as coisas que poderiam ser muito mais simples.

Ento, Keep It Stupid Simple (Mantenha isto estupidamente simples - KISS)!

Regra do escoteiro

"Deixe sempre o acamapamento mais limpo do que voc encontrou!" O mesmo vale para nosso cdigo. Devolva (Check in) sempre o cdigo melhor do que voc o obteve. Se todo desenvolvedor no time tiver esta viso, e devolver um pedacinho de cdigo melhor do que estava antes, em pouco temos teremos uma grande mudana.

Causa raiz

Sempre procure a causa raiz do problema, nunca resolva as coisas superficialmente. No dia-a-dia, na correria, tendemos a corrigir os problemas superficialmente e no adentrar neles, o que muitas vezes causa o re-trabalho!

Tente sempre procurar a causa raiz e resolver assim o problema de uma vez por todas!

Regras de design

Mantenha dados de configurao em alto nvel

Algo que toda aplicao tem so suas configuraes, como as conhecidas ConnectionStrings. Tente sempre deixar estas configuraes ou o parse delas em um nvel mais alto possvel.

Evite sobrescrever configuraes em mtodos dentro de Controllers ou algo do tipo. Se possvel, mantenha esta passagem no mtodo principal, no incio da aplicao e no mexa mais nisto!

Exemplo

Em diversas aplicaes que trabalho, crio sempre uma classe Settings no projeto base e depois no Startup das aplicaes populo ela com as configuraes. Isto garante que no teremos estas configuraes sendo escritas em todo lugar e tambm que no precisaremos do IConfiguration que fica no ASP.NET em projetos que no so Web.

MeuProjeto.Domain

public static class Settings {    public static string ConnectionString { get; set; }}

MeuProjeto.Api

public Startup(IConfiguration configuration){    Configuration = configuration;    Settings.ConnectionString = Configuration.GetConnectionString("connectionString");}

MeuProjeto.Infra

using(var connection = new SqlConnection(Settings.ConnectionString)) {    ...}

Polimorfismo no lugar de IFs

Um IF ou condicional, como o nome diz, traz uma tomada de deciso a nossa aplicao, o que implica no aumento da complexidade da mesma. No geral devemos evitar o uso excessivo destes.

Nestes cenrios, opte sempre pelo polimorfismo ao invs de tomar deciso em todo mtodo que cria.

Exemplo

Vamos tomar como base uma classe Pagamento, onde temos pagamento via Boleto ou Carto de Crdito, porm nos pagamentos via Boleto, caso o dia do vencimento seja sbado ou domingo (Final de semana), o mesmo pode ser pago no prximo dia til.

IMPORTANTE Esta regra no est 100% correta ou eficiente, apenas uma demonstrao

public class Pagamento {    public bool PodeSerPago() {        if(tipo == ETipoPagamento.Boleto)        {            if(vencimento.Day != IsWeekend())                return true;        }        if(tipo == ETipoPagamento.CartaoCredito)            ...    }}

Note que temos duas tomadas de deciso dentro do mtodo PodeSerPago, onde a primeira se refere apenas a pagamentos do tipo Boleto. Caso hajam mais formas de pagamento futuramente, como tratariamos este cdigo? Encheriamos de IF?

A soluo mais plausvel derivar da classe base Pagamento criando o PagamentoBoleto que sobrescreve o mtodo PodeSerPago, dando uma nova funcionalidade a ele.

public class Pagamento {    public virtual bool PodeSerPago() {        ...    }}public class PagamentoBoleto : Pagamento {    public override bool PodeSerPago() {        if(vencimento.Day != IsWeekend())            return true;    }}

Mult-thread

Sempre que necessrio utilize processamento em Threads separadas. J temos suporte a multi-threads e paralelismo no C# faz um bom tempo e o prprio Async/Await j ajudam nisso.

Exemplo

Sem async/await

[HttpGet("cursos")]public IActionResult Index([FromServices] IContentRepository repository){    ViewBag.Courses = repository.GetContents(EContentType.Course);    return View();}

Com async/await

[HttpGet("cursos")]public async Task<IActionResult> Index([FromServices] IContentRepository repository){    ViewBag.Courses = await repository.GetContentsAsync(EContentType.Course);    return View();}

Separe os cdigos mult-thread

Seguindo o mesmo exemplo acima, uma boa prtica manter o que assncrono separado do que sncrono, para no forar um mtodo a ser ou no assncrono por conta de outro trecho de cdigo.

Exemplo

public async Task<IEnumerable<Model>> GetAsync(){    var model = new Model();    model.Courses = await _context.Courses.ToListAsync();    model.Tags = _context.Courses.ToList(); // No async    return model;}

Utilize Async como sufixo

Se um mtodo assncrono, utilize sempre o sufixo async para identific-lo.

public async Task<IEnumerable<Model>> GetAsync()

Evite configuraes desnecessrias

Evite deixar configuraes no sistema s por que algum ainda no definiu como aquilo deve ser. Isto polui o cdigo e traz uma complexidade desnecessria.

Exemplo

public void ConfiguraUsoMySql() {    // ainda no sabemos se vamos ou no suportar MySQL tambm    throw new NotImplementedException();}

Utilize injeo de dependncia

Sempre que possvel utilize injeo de dependncia, ele vai tornar seu cdigo mais limpo e desacoplado.

Exemplo

Lei de Demeter

A Lei de Demeter (LoD) ou princpio do menor conhecimento um princpio que prega os seguintes pontos.

• Cada unidade deve ter conhecimento limitado sobre outras unidades: apenas unidades prximas se relacionam.
• Cada unidade deve apenas conversar com seus amigos.
• No fale com estranhos, apenas fale com seus amigos imediatos

Exemplo

public class Order() {     public Discount Discount { get; set; }}public class Discount() {     public decimal Amount { get; set; }    public void Apply() { ... }}

Mau exemplo

public class OrderHandler() {    var order = new Order();    order.Discount.Apply(); // <-}

Bom exemplo

public class Order() {     public Discount Discount { get; set; }    public void Place()     {        Discount?.Apply();    }}public class OrderHandler() {    var order = new Order();    order.Place();}

Regras sobre entendimento do cdigo

Seja consistente

Se voc executa algo de uma forma, execute todo o resto desta mesma forma. Seja consistente na forma com que aplica o cdigo. Siga sempre o padro definido.

Exemplo

// Codificando em inglspublic class CustomerRepository { ... }// Agora mudou para "portugls"public class ProdutoRepository { ... }// Agora  portuguspublic class RepositorioUnidadeMedida { ... }

// Utilizou sufixo ASYNC no mtodo assncronopublic async Task<Product> GetAsync() { ... }// Agora no usou mais =/public async Task<Course> Get() { ... }

Utilize variveis concisas

Opte por variveis concisas, mesmo que resultem em um nome maior. Elas devem ser auto-explicativas, sem a necessidade de comentrios ou informaes adicionais.

Exemplo

// Total do que?decimal total = 0;// Total do carrinho de comprasdecimal shoppingCartTotal = 0;

Obsesso primitiva

No dia-a-dia tendemos a nos focar apenas em tipos primitivos (Built-in), causando uma obsesso pelos mesmos. Podemos criar e usar objetos de valor (Value Objects) para suprir melhor esta necessidade.

Exemplo

Mau exemplo

public class Customer {    public string Email { get; set; }    public Customer     {        // Valida E-mail    }}public class Employee {    public string Email { get; set; }    public Customer     {        // Valida E-mail novamente    }}

Bom exemplo

// Value Objectpublic class Email {    public string Address { get; set; }    public Email     {        // Valida E-mail    }}public class Customer {    public Email Email { get; set; }}public class Employee {    public Email Email { get; set; }}

Evite dependncias lgicas

No escreva mtodos cujo funcionamento correto dependa de algo contido em sua classe.

Exemplo

Mau exemplo

public class Student {    public bool IsSubscriber { get; set; }    public void Xpto()     {        if(IsSubscriber)            ... // S executa se for assinante       }}

Bom exemplo

public class Student {    ...}public class Subscriber : Student{    public void Xpto()     {        ...            }}

Evite condicionais negativas

No C# a negao dada por um sinal de exclamao (!) que muitas vezes pode ser imperceptvel, ocasionando na m leitura do cdigo.

Exemplo

// Eviteif(!IsSubscriber) { ... }// Utilizeif(IsSubscriber) { ... }

Regras de nomes

Escolha nomes descritivos

Esolher bons nomes para classes, variveis e mtodos essencial para um cdigo limpo. Lembre-se que se voc precisa explicar seu cdigo, ento algo pode ser melhorado nele.

Exemplo

// Evitevar x = 256;// Durao do que? Qual a mtrica?int duration = 25;// Muito mais expressivoint durationInMinutes = 25;

Faa distines significantes

Utilize sempre nomes nos quais quem estiver lendo seu cdigo possa diferenciar seu significado de outros possveis nomes.

Exemplo

// Evitevar salario = 7500M;// Tem um significado maiorvar salarioEmReais = 7500M;

Utilize nomes pronunciveis e buscveis

Evite utilizar nomes difceis de pronunciar ou inventar nomes e convees para variveis, classes e mtodos. Lembre-se sempre da linguagem ubquoa e da importncia dela no cdigo.

Exemplo

// Evitevar strTexto = "Meu texto aqui";// Evitepublic void GenerateBoletoInLote() {}// Evitepublic void Cadastry() {}

Evite uso excessivo de strings

Quem nunca perdeu horas procurando um BUG que era apenas um problema de comparao de string? Evite digitar a mesma string vrias vezes, utilize constantes para isto.

Exemplo

// Eviteif(environment == "PROD")    ...// Utilizeconst string ENV = "PROD";if(environment == ENV)    ...

No use prefixo ou caracteres especiais

No utilize prefixo com o tipo da varivel, classe ou mtodo e NUNCA use espaos ou caracteres especiais nestes itens.

Exemplo

// Evitepublic class clsCustomer { ... }// Evitestring strNome = "Andr";// Evitevar situao - "Pendente";

Regras para funes ou mtodos

Pequenas e com apenas um objetivo

Mantenha suas funes ou mtodos o menor possvel. mais fcil ter mtodos menores e reutilizveis do que tudo dentro de um mtodo s.

Exemplo

// Evitepublic void RealizarPedido() {     // Cadastra o cliente    // Aplica o desconto    // Atualiza o estoque    // Salva o pedido}// Utilizepublic void SaveCustomer() { ... }public void ApplyDiscount() { ... }public void UpdateInventoy() { ... }public void PlaceOrder() { ... }

Utilize nomes descritivos

A mesma regra dos nomes anteriormente vista aqui se aplica para este cenrio. Mantenha nomes concisos, sem caracteres especiais.

Exemplo

// Evite// Calcular o que?public void Calcular() { ... }// Utilize// Calcula o ICMSpublic void CalcularICMS() { ... }

Opte por poucos parmetros

Evite exigir muitos parmetros para construo do objeto, assim como use e abuse dos Optional Parameters do C#.

Exemplo

// Evitepublic void SaveCustomer(string street, string number, string neighborhood, string city, string state, string country, string zipCode) { ... }// Melhorandopublic void SaveCustomer(Address address) { ... }

Cuidado com efeitos colaterais

Evite que uma funo altere valores de outra classe sem ser a dela. Isto chamado de efeito colateral.

Exemplo

// Evitepublic class Order {    public decimal Total { get; set; }}var order = new Order();// Qualquer um fora da classe Order // pode atualizar seu totalorder.Total = 250; 

// Utilizepublic class Order {    public decimal Total { get; private set; }    public void CalculateTotal() { ... }}var order = new Order();// Total  privado, ningum de fora consegue // modific-lo, evitando efeitos colateraisorder.Total = 250; // ERRO

No tome decises desnecessrias

No utilize os famosos "flags" para tomar decises dentro dos mtodos, divida-os em vrios mtodos ou at mesmo outras classes.

Exemplo

// Evitepublic class CustomerRepository {    public void CreateOrUpdate(Customer customer, bool create)    {        if(create)            ...        else            ...    }}

// Utilizepublic class CustomerRepository {    public void Create(Customer customer) { ... }    public void Update(Customer customer) { ... }}

Regras de comentrios

Um cdigo bom expressivo

Teoricamente, se voc precisa comentar uma parte do seu cdigo, por que algo est errado com ele, ele no est expressivo o suficiente.

No seja redundante

Evite comentrios que no fazem sentido algum ao contexto ou cenrio.

Exemplo

// Evite// Funo principal do sistemapublic void Main() { ... }

No feche os comentrios

No h necessidade de fechar os comentrios.

Exemplo

// Evite// Comentrio // <- Desnecessriopublic void Main() { ... }

Evite cdigos comentados

No deixe sujeira em seu cdigo, ao invs de deixar algo comentado, remova ele. Hoje temos versionadores de cdigo, voc pode "voltar no tempo" facilmente.

Exemplo

// Evitepublic void MinhaFuncao() {     // string texto = "1234";    // public void Metodo() {... }}

Inteo

Um bom uso de comentrios sobre a inteno de um mtodo, classe ou varivel (Varivel nem tanto).

Exemplo

// Utilize// Retorna a lista de produtos inativos// para o relatrio de fechamento mensalpublic IList<Product> ObtemProdutosInativos() {     ...}

Esclarecimento

Outro uso interessante para os comentrios so esclarecimentos sobre o cdigo.

Exemplo

// Utilizepublic void CancelarPedido() {     // Caso o pedido j tenha sido enviado    // ele no pode mais ser cancelado.    if(DataEnvio > DateTime.Now)    {        AddNotification("O pedido j foi enviado e no pode ser cancelado");    }}

Consequncias

Podemos utilizar comentrios para alertar sobre trechos do cdigo que podem ter consequncias mais srias. Neste caso recomendo o uso de um comentrio em XML mais elaborado.

Exemplo

// Utilize/// <summary>/// ATENO: Este mtodo cancela o pedido e estorna o pagamento/// </summary>public void CancelarPedido() {     ...}

Estrutura do cdigo

Separe conceitos verticalmente

Mantenha uma estrutura de pastas saudvel e organizada. No precisa criar uma pasta para cada arquivo, mas pode haver uma separao por contexto ou feature.

Exemplo

• MeuApp
  • MeuApp.Domain
    • MeuApp.Domain.Contexts
    • MeuApp.Domain.Contexts.PaymentContext
      • MeuApp.Domain.Contexts.PaymentContexts.Entities
      • MeuApp.Domain.Contexts.PaymentContexts.ValueObjects
      • MeuApp.Domain.Contexts.PaymentContexts.Enums
    • MeuApp.Domain.Contexts.AccountContext
      • MeuApp.Domain.Contexts.AccountContext.Entities
      • MeuApp.Domain.Contexts.AccountContext.ValueObjects
      • MeuApp.Domain.Contexts.AccountContext.Enums

Declare variveis prximas de seu uso

No crie todas as variveis juntas, no comeo da class ou mtodo, defina-as prximas de onde sero utilizadas.

Exemplo

// Evitevar total = 0;public void CreateCustomer() { ... }public void CreateOrder() { ... }public void UpdateCustomer() { ... }public void CalculateTotal() {     total = 250; // <- S  utilizada aqui}

// Utilizepublic void CreateCustomer() { ... }public void CreateOrder() { ... }public void UpdateCustomer() { ... }var total = 0;public void CalculateTotal() {     total = 250;}

Agrupe funcionalidades similares

Se uma funo pertence a um grupo dentro de um objeto, mantenha-as sempre por perto.

Exemplo

// Evitepublic void CreateCustomer() { ... } public void CheckInventory() { ... }public void CreateOrder() { ... }public void UpdateCustomer() { ... }public void CalculateTotal() { .. }

// Utilizepublic void CreateCustomer() { ... } public void UpdateCustomer() { ... }public void CheckInventory() { ... }public void CreateOrder() { ... }public void CalculateTotal() { .. }

Declare funes de cima para baixo

Ordenar as funes tambm importante. Alm da sua ordem de grandeza, suas assinaturas tambm devem ter uma boa oganizao.

Exemplo

// Utilizepublic void CreateCustomer(string name) { ... } public void CreateCustomer(string name, int age) { ... } public void CreateCustomer(string name, int age, Address address) { ... } public void CreateCustomer(string name, int age, Address address, bool active) { ... } 

Mantenha poucas e curtas linhas

Evite funes com linhas longas ou muitas linhas. No existe um nmero correto, mas com certeza quanto mais cdigo em uma funo, mais difcil de mant-la ser.

Exemplo

// Utilizepublic void CreateCustomer(string name) {     var customer = new Customer(name);    _repository.Customers.Add(customer);    _repository.SaveChanges();} 

No use alinhamento horizontal

No h necessidade de alinhar horizontalmente variveis, constantes ou mesmo propriedades.

Exemplo

// Eviteprivate   Long            requestParsingTimeLimit;protected Request         request;private   FitNesseContent context;this.context =            context;input =                   s.getInputStream()requestParsingTimeLimit = 900;

Use os espaos em branco corretamente

Utilize espao em branco para associar ou no itens relacionados. Uma boa IDE j far este trabalho por voc.

Exemplo

// Utilizeprivate void meuMetodo(String parametro) {  variavel++;  int outraVariavel = algumArray.length();  total += algumMetodo();  outraClasse.algumMetodo(variavel, total);  outroMetodo(total);}

No quebre a identao

Este item dispensa comentrios. Um cdigo no identado no pode ser enviado para o projeto.

Exemplo

// Evitepublic class MinhaClasse{var valor=12;Console.WriteLine(valor);}

Objetos e estruturas

Esconda estruturas internas

Este tpico abrange uma discusso extensa. Esconder a estrutura de um objeto, ou seja, privar as propridades relacioadas a dados dele, vai sempre trazer resultados positivos e negativos.

Particularmente, gosto de tornar os SET privados, mas no uma regra do meu cdigo e no aplico em todas as propriedades. Como consequncia, sempre precisamos de mais mtodos para manipulao destes valores.

Se os dados no fazem sentido para os objetos externos, no h discusso, mantenha-os privados.

Exemplo

public class NotificationContext{    private List<string> _notifications;    public void Add(string notification)     {        _notifications.Add(notification);    }    public bool IsValid() => _notifications.Any();    public IEnumerable Notifications { get => _notifications.AsEnumerable(); }}

Opte por estrutura de dados

Estruturas de dados representam a forma como os dados so organizados, podendo ser uma class ou um struct. Normalmente associamos as struct mais a estrutura de dados do que as classes, mas podemos estruturar dados com qualquer uma delas.

A diferena que ao usar class (OOP) temos recursos como abstrao, herana, polimorfismo, dentre outros.

Particularmente acho que a segmentao em objetos de valor um ponto chave neste item.

Exemplo

// Usando estruturaspublic struct Email {    public Email(string address)     {         // Permite apenas E-mails hotmail, gmail, yahoo...    }    public string Address { get; private set; }}public class Customer{    public Email Email { get; private set; }}

// Usando classespublic class Email {    public Email(string address)     {         // Permite qualquer tipo de E-mail    }    public string Address { get; private set; }}public class CommonEmail : Email{    public Email(string address)         : base(address)    {         // Permite apenas E-mails hotmail, gmail, yahoo...    }        }public class Customer{    public Email Email { get; private set; }}

Nos dois casos temos estruturas representando um E-mail como objeto de valor, porm no segundo cenrio, podemos criar extenses e ter uma maior flexibilidade.

Evite usar dados e objetos juntos

Este outro ponto polmico que muitos interpretam como manter nos objetos apenas propriedades enquanto seus comportamentos ficam em outros objetos.

Particularmente acho que a essncia de um objeto justamente o agrupamento de variveis e funes (Propriedades e mtodos). Neste ponto eu sempre mantenho os comportamentos nas entidades.

Em relao a manter parte com object e parte com struct eu confesso que a maior parte dos meus casos eu uso apenas o object. Pode ser vcio ou puro comodismo, mas acho estranho esta mistura.

Talvez uma abordagem que aplique estes conceitos de uma forma legal seja novamente o uso dos value objects.

// Objeto de valor, representa um endereo, sua estrutura de dadospublic class Address{    public string ZipCode { get; set; }    public string Street { get; set; }    public string Number { get; set; }    public string Neighborhood { get; set; }    public string City { get; set; }    public string State { get; set; }    public string Country { get; set; }}// Objeto do cliente... com seus comportamentospublic class Customer{    public Address BillingAddress { get; private set; }    public Address ShippingAddress { get; private set; }    public void ChangeBillingAddress(Address address) { ... }    public void ChangeShippingAddress(Address address) { ... }}

Instanciar poucas variveis

Evite instanciar muitas variveis nos objetos e seus mtodos. Faz uso maior das propriedades se possvel.

Exemplo

public class ShoppingCart{    public decimal Total { get; private set; }    public decimal CalculateTotal()    {        var total = 0; // Desnecessrio        foreach(var item in Items)            total += item.Price;    }}

// Melhorandopublic class ShoppingCart{    public decimal Total { get; private set; }    private decimal CalculateTotal()    {                foreach(var item in Items)            Total += item.Price;    }}

Classe base no deve saber sobre suas derivadas

Uma classe no deve saber sobre detalhes dos seus filhos. Nas verdade isto me soa to estranho que no vejo um cenrio onde uma classe pai consiga saber detalhes de seus filhos.

Exemplo

// N/A

Mais mtodos, menos tomadas de deciso

J comentamos bastante isto na parte de OOP dos cursos, mas fica aqui o reforo, sempre opte por ter mais mtodos, mais sobrecargas do que tomadas de deciso.

Exemplo

// Evitepublic class Order{    public void Pay(CreditCard card)    {        if(card == null)            // Pagamento via boleto        // Pagamento via carto    }}

// Utilizepublic class Order{    public void Pay()    {        // Pagamento via boleto    }    public void Pay(CreditCard card)    {        // Pagamento via carto de crdito    }}

Evite mtodos estticos

Classes e mtodos estticos so difceis de gerenciar, alm de serem compartilhados entre a aplicao como um todo. Imagina que voc tem uma classe esttica que tem uma lista de notificaes, esta lista seria compartilhada entre todas as requisies (Diversos usurios) em seu sistema.

// Evitepublic static class NotificationContext{    public static IList<Notification> Notifications { get; set;}}

// Utilizepublic class NotificationContext{    public IList<Notification> Notifications { get; set;}}

Testes

Um assert por teste

Utilize um e apenas um assert por teste. Mais de um assert pode confundir voc e comprometer a escrita do seu teste.

// Evite[TestMethod]public void ShouldReturnTrue {    Assert.AreEqual(true);    Assert.AreEqual(1);}

// Utilize[TestMethod]public void ShouldReturnTrue {    Assert.AreEqual(true);}

Legvel

Trate seus testes como parte fundamental do seu cdigo, no secundria. Os testes tem que ser organizados e bem escritos assim como o resto do seu software.

Exemplo

// N/A

Rpido

Um dos objetivos principais de um teste cobrir uma pequena poro do nosso cdigo. Normalmente estendemos esta ideia para a maior parte do cdigo possvel, ocasionando uma ampla gama de testes de unidade.

Dados estes testes, os mesmo so executados antes da publicao das nossas aplicaes, garantindo que no enviaremos nada com bugs para produo.

Porm, em cenrios mais crticos, o tempo dos deploys (Publicaes) extremamente importante, e se nossos testes demoram muito, podem impactar negativamente nisto.

Exemplo

// N/A

Independentes

Os testes no devem depender de entidades externas, nem de outros testes. Neste exemplo, volto a salientar o uso do DI e DIP.

Exemplo

Repetitvel

Devemos ter a possibilidade de repetir o mesmo teste, mas com parmetros diferentes.

Exemplo

[TestMethod][DataRow("[email protected]", "[email protected]")]public void ShouldValidateEmail(string email){    Assert.IsTrue(new Email(email).IsValid());}

Code smells

Code Smells so alguns sintomas que podemos identificar e que nos remetem a uma m aplicao do Clean Code de uma forma geral.

Rigidez

Seu software difcil de mudar. Qualquer mudana, por mnima que seja, causa uma cascata de outras mudanas.

Fragilidade

Uma simples mudana quebra seu software em diversos locais. o famosos "cobre o p, descobre a cabea".

Imobilidade

Voc no consegue reutilizar partes do seu cdigo em outros projetos por que isto requer um esforo gigantes. Em resumo, tudo est muito acoplado.

Complexidade desnecessria

Voc usa padres e arquiteturas que tornam seu cdigo mais burocrtico do que efetivo. o famoso "e se", onde pensamos em tudo que o software pode ter um dia e j "deixamos tudo pronto".

"E se eu quiser voar com meu carro um dia?", bem, se um dia voc quiser voar, a voc constri as asas, mas se no vai precisar voar agora, foca em construir apenas o carro.

Repetio desnecessria

Voc precisa repetir o mesmo cdigo em diversos lugares.

Opacidade

Seu cdigo difcil de entender.

Fontes

• Post em Ingls
• Livro Clean Code