Clean Code

Links uteis
[Link]
[Link]
[Link]
[Link]
[Link]
manutenção-e-o-das-de-oliveira-mc42f
[Link]

[Link]
kiss-principles#:~:text=The KISS principle in coding,easy to understand as
possible.

O que é

Se você está envolvido com programação há mais de dois ou três anos, é

bastante provável que já tenha se deparado com o código confuso, o que
resultou em um ritmo de trabalho mais lento. Cada nova adição ou

Clean Code 1
 modificação ao sistema exige uma compreensão das restaurações,
amarrações e remendos anteriores, a fim de incorporar novas
funcionalidades. Com o passar do tempo, essa bagunça pode se acumular
e se tornar tão complexa que se torna impraticável de ser corrigida. Nesse
ponto, parece não haver solução à vista. E para evitar que isso aconteça é
importante que o código não apenas funcione, mas que também seja
eficiente.

No mundo do desenvolvimento de software, escrever código limpo é mais

do que uma preferência estética - é uma prática fundamental para garantir
a manutenibilidade, escalabilidade e eficiência do código. O Clean Code, ou
código limpo, refere-se a um estilo de programação que prioriza a
legibilidade, simplicidade e clareza.

O QUE É - gabi

Todo desenvolvedor já passou por um momento de estresse quando abriu

um código e demorou muito tempo para entender o que se passava por ali.
...as vezes algum ajuste simples acaba demorando mais tempo do que o
previsto por conta da dificuldade de entendimento do código desenvolvido.
Uma das formas de evitar isso é utilizando as práticas de Clean [Link]
o que é Clean Code? Bom, existem diversas definições que circundam o
significado de um código limpo: "Grady Booch, Cientista-chefe de
Engenharia de Software da IBM Research, por exemplo, é citado pelo autor
por considerar que:"O código limpo é simples e direto.Código limpo parece
uma prosa bem escrita. Código limpo nunca obscurece a intenção do
designer, mas é completo de abstrações nítidas e linhas simples de
controle." Já Michael Feathers, autor de"Working Effectively with
LegacyCode", coloca a palavra "cuidado" como central para um código
limpo."
Mas apesar das diversas discussões sobre seu significado, desenvolver um
código limpo significa aplicar técnicas que facilitam a escrita e leitura do
que foi [Link] grandes empresas, essa prática é essencial,
principalmente porque a programação acaba sendo uma atividade social,
muitos desenvolvedores tem acesso ao mesmo tempo e recorrentemente

Clean Code 2
 as mudanças de negócio acabam fazendo com que haja necessidade de
alterações no código. Por isso, manter as práticas de Clean Code, faz com
que todos osdesenvolvedores que tenham contato com o que foi
desenvolvido tenham rápido e fácil entendimento, agilizando o processo de
desenvolvimento.66TÉCNICAS• VARIÁVEIS• FUNÇÕES• SOLID• DESIGN
PATTERNS

Vantagens

A facilidade de implementar novas funcionalidades ao código;

Um dos principais benefícios do Clean Code é que ele torna a
manutenção do software mais fácil. Com código limpo, é mais simples
localizar e corrigir erros, adicionar novos recursos e fazer melhorias. Os
programadores podem economizar tempo valioso que seria gasto
decifrando código mal escrito e, em vez disso, concentrar-se em
melhorar a funcionalidade do software.

Colaboração eficaz

Projetos de software geralmente envolvem várias pessoas trabalhando

em conjunto. Com código limpo, a colaboração se torna mais eficaz. Os
membros da equipe podem entender o código uns dos outros com mais
facilidade, o que resulta em uma comunicação mais eficaz e em menos
conflitos. Além disso, novos membros da equipe podem se integrar
mais rapidamente e começar a contribuir de maneira significativa.

Tornar o código adaptável e eficaz;

Melhorar o desempenho, evitando funções e parâmetros redundantes.

Redução do Tempo de Desenvolvimento

Embora escrever código limpo possa levar um pouco mais de tempo

inicialmente, a longo prazo, isso pode economizar tempo. Código
confuso e complexo pode resultar em atrasos e retrabalho, enquanto o
Clean Code permite um desenvolvimento mais rápido e eficiente.

GABI
VANTAGENS

Clean Code 3
 Facilita a manutenção: com o código limpo, é mais fácil encontrar e
corrigir erros e desenvolver melhorias.• Aumenta a velocidade de
desenvolvimento: deixando o código de uma forma simples de
entender, o entendimento é mais fácil, o que faz com que o desenvolver
perca menos tempo entendendo o cógido e tenha mais temno nara
desenvolver ndesenvolver melhorias.

Aumenta a velocidade de desenvolvimento: deixando o código de uma

forma simples de entender, o entendimento é mais fácil, o que faz com
que o desenvolver perca menos tempo entendendo o cógido e tenha
mais tempo para desenvolver o que for necessário.

Melhora a qualidade de software: Reduz a quantidade de códigos

desnecessários no projeto, um código bem escrito está menos
condicionado a sofrer erros críticos, o que é um benefício tanto para
futuros desenvolvedores quanto para os clientes que vão usufruir do
software desenvolvido.

Colaboração eficaz: Dentro de equipes, os códigos são entendidos com

mais facilidade, o que resulta em uma comunicação mais eficaz e em
menos conflitos, além de proporcionar rápido entendimento para novos
desenvolvedores que se integrarem nas equipes

Tópicos

KISS (Keep It Simple, Stupid)

O princípio KISS, abreviação de "Keep It Simple, Stupid" (Mantenha

Simples, Estúpido), destaca a importância da simplicidade na criação
de um software. A ideia é evitar o uso de estruturas de controle
complexas quando não são necessárias.

Ao optar por manter nosso código simples, podemos aprimorar sua

compreensão, facilidade de uso, facilidade de manutenção e criação de
testes unitários menos complexos.

Exemplos

descartar a complexidade, quebrar as funções onde cada parte

teria uma única responsabilidade

Clean Code 4
 // Exemplo complexo:
public void processarDados() {
// Lógica para processar os dados
// Lógica para validar os dados
// Lógica para exibir resultados
// ...
}

// Versão simplificada:
public void processarDados() {
processar();
validar();
exibirResultados();
}

private void processar() {

// Lógica para processar os dados
}

private void validar() {

// Lógica para validar os dados
}

private void exibirResultados() {

// Lógica para exibir resultados
}

nomear variáveis e funções de forma clara e descritiva

// Exemplo não descritivo

int x = 10;

// Exemplo descritivo
int numeroDeAlunos = 10;

Evite aninhar estruturas de controle em excesso:

Clean Code 5
 // Exemplo complexo:
if (condicao1) {
if (condicao2) {
if (condicao3) {
// ...
}
}
}

// Versão simplificada:
if (condicao1 && condicao2 && condicao3) {
// ...
}

DRY (Don't Repeat Yourself)

O princípio DRY, que significa "Don't Repeat Yourself" (Não Se Repita),

destaca a importância de evitar a repetição de código em nossas
aplicações.

A essência do DRY é garantir que haja apenas uma representação

definitiva do conhecimento dentro do sistema. Ao eliminar a duplicação
de código, conseguimos melhorar a capacidade de manutenção,
reduzir a complexidade e diminuir a possibilidade de introduzir erros. A
presença de código duplicado pode resultar em inconsistências e
dificultar as alterações futuras.

Para aderir ao princípio DRY, devemos buscar por código limpo,

modular e reutilizável. Isso pode ser alcançado através de técnicas
como o uso de métodos, classes e herança, e interfaces.

Exemplo

O método AddIntegers é reutilizável e elimina a necessidade de

duplicar código para adição

class Program {
static void Main(string[] args) {
int a = 5;

Clean Code 6
 int b = 10;
int x = 10;
int y = 20;

int sum1 = AddIntegers(a, b);

int sum2 = AddIntegers(x, y);

[Link]($"Sum of a and b is: {s

}

static int AddIntegers(int num1, int num2)

{
return num1 + num2;
}
}

YAGNI (You Ain't Gonna Need It)

O princípio YAGNI, derivado de "You Ain't Gonna Need It" (Você Não
Vai Precisar Disso), instrui os desenvolvedores a incorporarem
funcionalidades somente quando absolutamente necessárias, não
quando supõem ou preveem que algo pode ser útil no futuro. Porque no
final, geralmente acontece que você não precisa disso, ou que o que
você precisa é diferente do que você esperava.
Essa abordagem minimalista destaca a importância de priorizar a
entrega oportuna dos recursos mais essenciais. Ao evitar a inclusão de
funcionalidades supérfluas, podemos:

agilizar o processo de desenvolvimento: A equipe se concentra em

entregar os requisitos atuais de forma eficaz. Eles não gastam
tempo e esforço em suposições.

Simplificar a complexidade,

Ampliar a flexibilidade do sistema: você não precisa encontrar

maneiras de usar soluções abaixo do ideal que já havia
desenvolvido antes de ter uma visão completa

Reduzir custos em um projeto com recursos limitados.

Clean Code 7
 SOLID

S — Single Responsiblity Principle (Princípio da responsabilidade

única)

O — Open-Closed Principle (Princípio Aberto-Fechado)

L — Liskov Substitution Principle (Princípio da substituição de

Liskov)

I — Interface Segregation Principle (Princípio da Segregação da

Interface)

D — Dependency Inversion Principle (Princípio da inversão da

dependência)

Naming convention convensão de nomes →

[Link]
b0ce80459b81

Nomes descritivos

// Evite
// Calcular o que?
public void Calcular() { ... }

// Utilize
// Calcula o ICMS
public void CalcularICMS() { ... }

Faça distinções significativas: distinção de nomes na qual o leitor

compreenda a diferença

getActiveAccount()
getActiveAccounts()
getActiveAccountInfo()
// qual das 3 funções chamar?

Nomes significativos e passiveis de busca: não tenha medo de

nomes grandes

Clean Code 8
 for (int j=0; j<34; j++){
s+=(t[j]*4)/5;
}

----------------------------------------------------

int realDaysPorIdealDay = 4;
const int WORK_DAYS_POR_WEEK = 5;
int sum = 0;
for (int j=0; j< NUMBER_OF_TASKS; j++){
int realTaskDays = taskkEstimate[j] * realDaysPo
int realTaskWeeks = (realDays / WORK_DAYS_POR_WEE
sum+= realTaskWeeks;
}

→ Nomes de classes tem que ter nomes com substantivos pq eles

representam algo: Customer , User , Account
→ Nomes de metodos tem que ter nomes com verbos pq eles fazem
alguma coisa, tem uma ação: Post , Payment , Delete

Parâmetros de funções → [Link]

boas-praticas-para-argumentos-de-funcao

Funções devem ser pequenas

→ mais abstrato - responsabilidade dividida, nao gera dependencia e é
mais facil de modificar, sem quebrar algo

// Evite
public void RealizarPedido()
{
// Cadastra o cliente
// Aplica o desconto
// Atualiza o estoque
// Salva o pedido
}

Clean Code 9
 // Utilize
public void SaveCustomer() { ... }
public void ApplyDiscount() { ... }
public void UpdateInventory() { ... }
public void PlaceOrder() { ... }

Comentários
→ Evite codigos comentados
Não deixe sujeira em seu código, ao invés de deixar algo
comentado, remova-o. Hoje temos versionadores de código, você
pode "voltar no tempo" facilmente. Alem de que as funções e
atributos devem ter o nome descritivo o suficiente para entender a
funcionalidade daquilo

Exemplo

// Evite
public void MinhaFuncao()
{
// string texto = "1234";

// public void Metodo() {... }

}

// Utilize

// Retorna a lista de produtos inativos

// para o relatório de fechamento mensal
public IList<Product> ObtemProdutosInativos()
{
...
}

Tratamento de erro

Testes Unitários

Clean Code 10
 Unit Tests
TDD significa Desenvolvimento Orientado por Testes (Test Driven
Development), e trata-se de uma prática de desenvolvimento de
software onde a codificação das funcionalidades começa a partir
da escrita de testes unitários.

TDD nos pede para escrever os testes primeiro, antes de escrever o

código de produção. Mas essa regra é apenas a ponta do iceberg

Primeira Lei – Você não pode escrever código de produção antes de

escrever um teste unitário reprovado.

Segunda Lei – Você não pode escrever mais de um teste unitário do

que for suficiente para falhar, e não compilar é falhar.

Terceira Lei – Você não pode escrever mais código de produção do

que o suficiente para passar no teste atualmente reprova

→ Manter os testes limpos

→ teste limpo? A legibilidade: clareza, simplicidade e densidade
de expressão

Quanto mais sujos os testes, mais difíceis são de mudar, e o

problema é que os testes devem mudar à medida que o código
de produção evolui. Quanto mais emaranhado o código de teste,
mais provável é que você gaste mais tempo criando novos testes
do que para escrever o novo código de produção.
→ Os testes habilitam as -ilities

São os testes unitário que mantêm nosso código flexível,

sustentável e reutilizável. A razão é simples. Se você tem testes,
não tem medo de fazer alterações no código! Sem testes, toda
mudança é um possível bug. Não importa o quão flexível seja
sua arquitetura, não importa o quão bem particionado seu
design, sem testes você ficará relutante em fazer alterações por
causa do medo de introduzir bugs não detectados.

→ Uma afirmação por teste

toda função de teste deve ter uma e apenas uma declaração
‘assert‘

→ Conceito Único por Teste

Clean Code 11
 Talvez uma regra melhor seja testar um único conceito em cada
função de teste. Não queremos funções de teste longas que
testam coisas diversas, uma após a outra.

F.I.R.S.T
Os testes de limpeza seguem cinco outras regras que formam a
sigla acima:

Fast (rápido): Os testes devem ser executados rapidamente para

prover feedback o quanto antes ao time, e quando estes são lentos,
acabam sendo deixados de lado.

Independent (independente): Um teste não pode depender de

outro, senão a falha em um teste pode acarretar em diversos outros
testes falhando erroneamente e causando uma impressão errada ao
time

Repeatable (repetível): O mesmo teste que é executado em

ambiente local deve poder ser executado em diferentes tipos de
ambiente, como integração, QA, homologação e produção.

Self-validating (auto-verificável): Testes ou passam ou

falham. True ou False, simples assim.
Timely (oportuno/feito a tempo): Os testes de unidade devem ser
escritos um pouco antes do código de produção que o faz passar.
Aplicações devem ser projetadas para facilitar a testabilidade.

Clean Code 12