1 / 35

CLEAN
CODE

O guia pragmático pros devs
Frontend não passarem vergonha.

Não decore. Aprenda no Código.

by Walteann Costa

2 / 35

Escrever pra máquina vs para humanos

Qualquer um consegue escrever um código que o Computador ou o V8 Engine consiga compilar. A máquina não liga para nomes como let x = 2;

O problema é que Lemos código 10 VEZES mais do que escrevemos! O verdadeiro teste de um desenvolvedor Pleno/Senior é escrever códigos tão óbvios e límpidos que os colegas de equipe não precisem desvendar um "quebra-cabeças" para dar manutenção.

Vamos dissecar agora os 8 Pilares Radicais de Clean Code adaptados para o ambiente Front-end contemporâneo.

3 / 35

Pilar 1 - Nomes Significativos

O fim dos acrônimos adivinháveis

Segundo Bob Martin: "O nome de uma variável ou função deve nos dizer por que ela existe, o que faz e como é usada.".

Se um nome precisa de um comentário logo ao lado da declaração para você explicar o que de fato a mágica daquela Action faz, o nome já falhou miseravelmente em sua missão!

4 / 35

Nomes Significativos - Exemplo 1 💻

Variáveis Semânticas vs Adivinhação

O que evitar? Letras avulsas, listas soltas e diminutivos criptografados.

// ❌ ERRADO: Uma semana depois você não lembrará o que é D.
const d = 10; // data de vencimento em dias?? dias?? meses??

let ctn = 0;
function calc(u, a) {
  if (u.age > a) { ctn++; } // u.a? u.age? u.amount?
}

// ✅ CERTO: O nome da variável conta uma estória fluída
const daysUntilExpiration = 10;

let activeUsersCount = 0;
function countEligibleUsers(user, minimumAge) {
  if (user.age > minimumAge) { activeUsersCount++; }
}

💡 O Porquê evitar:

O "encurtamento preguiçoso" faz o seu cérebro e o da equipe rodarem ciclos de processamento mental para mapear memórias (Ex: O que era o u mesmo?). Código lê-se feito jornal, deve ser óbvio, pesquisável num Cmd+F e claro.

5 / 35

Nomes Significativos - Exemplo 2 💻

O Terror dos "Magic Numbers"

O que evitar? Hardcodar algoritmos complexos baseados em Inteiros literais cegos.

// ❌ ERRADO: O que diabos significa o número 86400000?
setTimeout(() => {
  logoutUser();
}, 86400000);

if (user.roleId === 4) { deleteDatabase(); }

// ✅ CERTO: Converta a matemática em Constantes Textuais Vivas!
const MILLISECONDS_IN_A_DAY = 86400000;
setTimeout(() => {
  logoutUser();
}, MILLISECONDS_IN_A_DAY);

const SYSTEM_MASTER_ROLE_ID = 4;
if (user.roleId === SYSTEM_MASTER_ROLE_ID) { ... }

💡 O Porquê evitar:

Números mágicos escondem o Domínio do negócio. Se futuramente a permissão "Master" mudar para o banco de número 5, alguém teria de fazer uma busca perigosa por todos os "números 4" soltos pela codebase inteira e correndo risco de causar estragos.

6 / 35

Nomes Significativos - Exemplo 3 💻

Boolean Arguments Flagging Sujo

O que evitar? Múltiplos parâmetros true/false mudando a função atirando para todo lado.

// ❌ ERRADO: Quem lê a chamada acha a lógica incompreensível.
// O que são esses booleans na declaração File?
createFile('report.pdf', true, false);

function createFile(name, isTemp, isEncrypted) { ... }

// ✅ CERTO: Crie funções diferentes! Ou use Objetos nomeados.
createTempFile('report.pdf');
createEncryptedFile('report.pdf');

// Ou se usar options num objeto (Destructuring Object):
createFile('report.pdf', { isTemp: true, isEncrypted: false });

💡 O Porquê evitar:

Aturar Flags booleanas soltas como argumento grita aos céus que a sua função faz mais de uma coisa dependendo do switch! Fora o inferno de leitura na invocação (Ninguém sabe o que o true significa sem usar Command+Click pra vasculhar a Type).

7 / 35

Pilar 2 - Funções Focadas

Pequenas, menores ainda e fazendo uma coisa.

A teoria define: "As funções devem ser pequenas. A segunda regra para funções é que elas devem ser menores ainda."

É insalubre rolar o Scroll do mouse por 400 linhas para ler o Método "ValidatePayment". Uma função deve ser um tijolo. Se ela está formatando moeda, validando erro, e enviando Toast Notification... ela virou um condomínio, não um tijolo!

8 / 35

Funções - Exemplo 1 💻

O Código Flecha (Arrow Code) vs Early Returns

O que evitar? Alinhamentos de identação monstruosos encavalando sub-ifs seguidos.

// ❌ ERRADO: Identações piramidais impossíveis de acompanhar.
function checkout(user) {
  if (user) {
    if (user.isAuthenticated) {
      if (user.cart.length > 0) {
        // Sucesso 4 abas para dentro...
      } else { throw new Error('Vazio') }
    }
  }
}

// ✅ CERTO: Inversão Guard-Clause (Bouncer Pattern).
function checkout(user) {
  if (!user || !user.isAuthenticated) return;
  if (user.cart.length === 0) throw new Error('Vazio');

  // Caminho Limpo Totalmente fora dos parênteses infernais!
  finishPayment(user.cart);
}

💡 O Porquê evitar:

Quanto mais fundo a indentação avança em colunas para a direita, gigantesca fica a carga cognitiva de manter a cadeia mental de negações de Ifs e Elses empilhados. O Early Return devolve o fluxo na cara do erro e despolui a linha principal!

9 / 35

Funções - Exemplo 2 💻

Listas Intermináveis de Parâmetros

O que evitar? Funções exigindo 4, 5 ou 6 argumentos posicionais quebrando ordens.

// ❌ ERRADO: Imagina chamar isso errando a posição de uma Type
function createUser(name, age, email, role, avatar, status) {
  ...
}

// O terror posicional (Erro ao preencher nulo fora de ordem):
createUser('Joao', 20, null, 'jo@c.co', 'Admin' ...);

// ✅ CERTO: Acima de 2/3 parâmetros? Transforme em um Object.
function createUser(options: {
  name: string;
  age: number;
  email: string;
  role: string;
}) { ... }

// Javascript seguro garantido pela chave, e sem ordem cega:
createUser({ name: 'Jo', role: 'Admin', age: 20 ... });

💡 O Porquê evitar:

A ordem posicional quebra fácil! Funções engessadas com muitos parâmetros destroem os testes e obrigam você a pular furos com undefined na assinatura se um dia o campo número 3 deixar de ser obrigatório na plataforma.

10 / 35

Funções - Exemplo 3 💻

Do One Thing. Fazer Uma Única Coisa.

O que evitar? Misturar parsing gráfico, chamadas lógicas e validações no mesmo bloco.

// ❌ ERRADO: O Método é mentiroso, ele não faz só "Pagamento"!
function processPay(cart) {
  if (!cart.hasItems) throw new Error('Carrinho vazio!');
  
  const taxes = cart.price * 0.1;           // Calculou.
  Api.post('/pay', cart.price + taxes);     // Enviou Servidor.
  DOM.notify('Enviado Email de Sucesso!');  // Tocou na UI?!
}

// ✅ CERTO: Abstração de Passos (Composing Blocks)
function processPay(cart) {
  validateCart(cart);
  const finalPrice = calculateTaxesFor(cart.price);
  
  return Api.post('/pay', finalPrice);
}
// O componente fora daqui cuidará da UI e Alertas Notification.

💡 O Porquê evitar:

Se a sua lógica visual atrelou envios nativos de notificação da UI dentro de uma função de Matemática Tributária, testar isso requer instanciar O Sistema Inteiro Gráfico. Desacople! Funções utilitárias puras não manipulam DOM de surpresa!

11 / 35

Pilar 3 - Os Comentários

Não comente o código ruim. Reescreva-o.

A teoria define: "Qualquer comentário é, no fundo, uma falha de expressão na linguagem.".

Comentários MENTEM. O código muda ao longo dos anos, e desenvolvedores quase nunca lembram de atualizar a linha verde inútil do comentário. No fim, eles desacompanham a lógica e geram extrema confusão.

12 / 35

Comentários - Exemplo 1 💻

Remendando Nomes Pífios

O que evitar? Escrever parágrafos para explicar o que um IF horroroso significa.

// ❌ ERRADO: Usando comentários como muleta pra código bizarro
// Verifica se a string contem flag X marcando que é corporativo
// e verifica o dia da criação pra não bater no server de backup
if (user.tags.includes('X') && account.createdAt.getDay() !== 0) {
  ...
}

// ✅ CERTO: Funções semânticas destroem a necessidade das Muletas!
const isCorporateCard = user.tags.includes('X');
const isWorkingDay = account.createdAt.getDay() !== 0;

if (isCorporateCard && isWorkingDay) { 
  ... 
}

💡 O Porquê evitar:

Ao invés de passar 2 minutos escrevendo um poema de Shakespeare detalhando o quanto de lixo matemático aquela condição faz... Basta extrair a verificação para uma constante nomeada! O leitor entenderá o IF intuitivamente de graça.

13 / 35

Comentários - Exemplo 2 💻

O cemitério de Código Morto/Zumbi

O que evitar? Deixar Blocos imensos "Comentados/Anulados" com medo de perder.

// ❌ ERRADO: O projeto virou um lixão obsoleto radioativo
function fetchList() {
  /* 
   const legacyApi = new OlxLibSystemAdapter();
   if (legacy) return fetchLegacy(); 
   -- comentado em 2019 --
  */
  return newMethodList();
}

// ✅ CERTO: Delete! Pressione Backspace sem nenhum dó.
function fetchList() {
  return newMethodList();
}

// Seu Git History / Blame tem o histórico congelado blindado no tempo.
// Você não vai perder a pérola antiga!

💡 O Porquê evitar:

O "Deixa aí que posso precisar amanhã" vai acumulando poeira nos repositórios criando um medo visual brutal em recém-contratados ("Isso aqui tá comentado mas é importante? Eu deleto?"). É puro Lixo! Controle de versão (Git) existe 100% pra isso.

14 / 35

Comentários - Exemplo 3 💻

Ruído Inútil Redundante (JSDoc Noise)

O que evitar? Gastar linhas coloridas descrevendo literalmente o óbvio visual.

// ❌ ERRADO: Descrevendo o que os Types Estritos já me disseram
/**
 * Pega o Id
 * @param {string} id - a String ID recebida
 * @return {number} - retorna ID numero
 */
function getId(id: string): number { return Number(id); }

// ✅ CERTO: Comente apenas o "O PORQUÊ" Excepcional de certas tretas!
// Workaround da BUG do Safari Mobile que perde o parse do Zero a Esquerda
function parseUserId(id: string): number { 
   return SafariEngineForceMath(id); 
}

💡 O Porquê evitar:

Escrever linhas mortas como // Instancia usuario em cima de um nítido new User() é poluição literária ruidosa inútil. Comentários Sadios existem única e exclusivamente para Explicar Motivações Ocultas (Ex: Razões de Negócio Exóticas ou Correções de Bug do Browser).

15 / 35

Pilar 4 - Formatação & Mutabilidade

A organização limpa da vida dos dados

A teoria define: "O código deve ser formatado como uma reportagem confiável que instigue leitura limpa de dependências e estados".

Programadores inexperientes deixam rastros de variáveis flutuantes let serem assombradas por infinitas mutações lá por baixo da tela inteira, gerando Side-Effects caóticos. Preze por arquivos blindados em "Exports Limpos" e "Mutabilidade Zero"!

16 / 35

Estrutura Front - Exemplo 1 💻

A praga silenciada das Variáveis Mutações (let/var)

O que evitar? Declarar estados fantasmas perdidos na montanha que sofrem Reassigneds.

// ❌ ERRADO: Rastrear de Onde um LET mudou de nome é torturante
let taxAmount = 0;

if (userIsVIP) taxAmount = product.price * 0.05;
else if (userIsGlobal) taxAmount = product.price * 0.12;
else taxAmount = product.price * 0.2;

// ✅ CERTO: Constantes Absolutadas baseadas em Blocos Seguros Imediatos!
const taxAmount = calculateTaxFor(user.role, product.price);

// ⬇️ Onde a função fora dali é cristalina:
const calcRules = { VIP: 0.05, GLOBAL: 0.12, DEFAULT: 0.2 };
const calculateTaxFor = (role, price) =>
  price * (calcRules[role] ?? calcRules.DEFAULT);

💡 O Porquê evitar:

Quando você adota a diretriz sagrada de "Prefer Const Over Let", elimina bugs terríveis de colaterais, impedindo que partes do HTML/Componente recebam a string corrompida por acidente lá do final da leitura. Valores devem fluir e imobilizar!

17 / 35

Estrutura Front - Exemplo 2 💻

Spaghetti de Imports Infinitos (Hell paths)

O que evitar? Poluir a parte superior da classe com Diretórios caçados em ../../../..

// ❌ ERRADO: Assustador, ilegível, atrelado a caminhos mortos físicos
import { UserDTO } from '../../../../../core/data/user.dto';
import { AuthUtils } from '../../../../../core/utils/auth';
import { Pipes } from '../../../../../core/pipes/string.pipe';

// ✅ CERTO: Path Aliases (TSConfig) + Index Barrels de Exportação Limpas!
// O arquivo de destino centraliza em "export * from './user.dto'"

import { UserDTO, AuthUtils, Pipes } from '@App/Core';

💡 O Porquê evitar:

Estrutura limpa de importação é saúde mental. Path aliases blindados e Barrels reduzem 15 mil linhas de código em Refatorações grandes de realocações de pastas. O import mergulha na semântica real (Um módulo raiz) invés da hierarquia estúpida do seu Disco Local.

18 / 35

Estrutura Front - Exemplo 3 💻

Enjoos de Clumps e Obesidade de Arquivos (God Files)

O que evitar? Deixar Types, Interfaces, Constantes e Classes tudo no Component.

// ❌ ERRADO: Um amontoado insuportável no topo do "home.component.ts"
export interface IHomeData { desc: string; }
export const TIMEOUT = 5000;
export const parseHome = () => ...

@Component({...})
export class HomeComp { ... }

// ✅ CERTO: Coesão! O Arquivo TS de Classe existe só pra Classe.
// Types moram em "home.model.ts"
import { IHomeData } from './models';

// Constants moram em "home.config.ts"
import { HOME_CONFIG } from './config';

💡 O Porquê evitar:

Deixar Types vazarem dentro de classes causa Acoplamentos Cíclicos circulares (Módulo A chamando B que importa O Type dentro do arquivo de Classe de A)! Ao isolar as Contratações (Interfaces .models) em arquivos secos puros, o TS respira maravilhosamente bem!

19 / 35

Pilar 5 - Lógica & Condicionais

A raiz dos Bugs: Ifs enjaulados sujos.

A teoria define: "O cérebro tem extrema dificuldade em parsear cadeias duplas negativas ou engarrafar lógicas polinomiais de Switches em métodos focados.".

A complexidade Ciclomática (números pesados de Switches, whiles, ifs enfiados juntos) é o que mais envelhece o código legado. Domar as Condicionais convertendo lógicas bizarras em Mapas Diccionários fluidos é o supra-sumo do Clean-Code Dinâmico!

20 / 35

Condicionais e Lógica - Exemplo 1 💻

Ifs Negativos com Duplos Negativos Exóticos

O que evitar? Obrigar o cérebro a inverter significados toda hora.

// ❌ ERRADO: Inversões semânticas dão um no no Cérebro
function isNotVerifiedUser(user) { return !user.verified; }

// Leia isso em voz alta: Se não (não for um usuário verificado)...
if (!isNotVerifiedUser(user)) {
   ...
}

// ✅ CERTO: Nomes Positivos sempre dominam a cadeia natural!
function isVerified(user) { return user.verified === true; }

if (isVerified(user)) {
   // Entendido na primeira batida de olho, leitura humana!
}

💡 O Porquê evitar:

Na Programação Dinâmica, um Boolean Negativo acompanhado de um operador NOT (!) soa torturante (se 'Não for Inválido' então faça). Escrever funções puramente positivas garantem a harmonia da conversação com a leitura e diminui bugs bestiais por deslizes de acentos.

21 / 35

Condicionais e Lógica - Exemplo 2 💻

Condicionais de Múltiplos AND/OR no View Code

O que evitar? Jogar expressões matemáticas abertas no meio da execução.

// ❌ ERRADO: Carga Cognitiva de parsear as regras ao vivo.
if (user.country === 'BR' && user.age > 18 && user.doc !== null) {
  enablePremiumGate();
}

// ✅ CERTO: Encapsule a Expressão inteira que dê vida na Semântica!
// O Domínio e as Regras ficam blindadas na Constante Avaliadora! 
const isAbleToBuyPremium = 
  user.country === 'BR' && user.age > 18 && !!user.doc;

if (isAbleToBuyPremium) {
  enablePremiumGate();
}

💡 O Porquê evitar:

Ao espalhar "ifs pelados gigantes" o leitor gasta 10 segundos entendendo os andares (&&) para no final não saber o que aquele combo realmente significa para os Negócios da Empresa. Encapsular a conta gigante numa Constante nomeada gera fluidez imediata à abstração e brilha forte!

22 / 35

Condicionais e Lógica - Exemplo 3 💻

Switch Statements Infinitos espalhados sem Fim

O que evitar? Ficar repetindo Switches Case nas Views mudando ícones de Types.

// ❌ ERRADO: E se amanhã no projeto entrar um Animal novo? Crash!
function getAnimalSound(type) {
  switch(type) {
    case 'Dog': return 'Au Au';
    case 'Cat': return 'Miau';
    case 'Bird': return 'Piu';
    default: return 'Desconhecido';
  }
}

// ✅ CERTO: O Polimorfismo Bruto (Javascript Object Hash Maps).
const animalSoundsStrategy = {
  Dog: 'Au Au',
  Cat: 'Miau',
  Bird: 'Piu',
  default: 'Desconhecido'
};

function getAnimalSound(type) {
  return animalSoundsStrategy[type] || animalSoundsStrategy.default;
}

💡 O Porquê evitar:

O Switch-Case suja verticais brutais no Typescript. Substituí-los por Mapas de Chaves (Dictionary/Record Objects) isola as possibilidades Extensíveis do Sistema sem entupir funções de controles complexos, garantindo 100% de flexibilidade caso chaves venham do Back-End dinamicamente!

23 / 35

Pilar 6 - DRY (Don't Repeat Yourself)

O pesadelo do Ctrl+C Ctrl+V guiado a pressa.

A teoria define: "Cada pedaço de conhecimento ou lógica de negócios deve ter uma, e apenas uma, representação autoritativa no sistema inteiro.".

O Programador Pragmatico abomina escrever a mesma equação de CSS ou TypeScript duas vezes. Se você precisa aplicar o mesmo efeito de UI em 3 telas copiando as Divs em todas elas... você falhou em abstrair componentes. O retrabalho será letal!

24 / 35

DRY / Repetição - Exemplo 1 💻

Camadas Visuais Copiadas sem Dó

O que evitar? Escrever a mesma Box de Notificação solta crua em cada Action File.

<!-- ❌ ERRADO: Na Tela de Perfil, Pagamento e Carrinho tá socado isto -->
<div class="rounded-lg border bg-blue text-white p-4 drop-shadow">
  <h1>Atenção Usuário</h1>
  <p>Operação realizada.</p>
</div>

<!-- ✅ CERTO: Componentizou uma Única Vez. A manutenção é Central! -->
<app-alert-box title="Atenção" type="success">
  Operação realizada.
</app-alert-box>

💡 O Porquê evitar:

Se amanhã o Marketing decidir que a borda do Alert Box não é mais quadrada, é arredondada, e a cor mudou... Pagar desenvolvedores pra ficarem dando Localizar/Substituir em 80 telas do projeto buscando onde as divs estavam escondidas é um completo rasgo de dinheiro corporativo.

25 / 35

DRY / Repetição - Exemplo 2 💻

Magic Strings Mutantes

O que evitar? Atirar pedaços de textos soltos de chaves de API/Config pelo Type.

// ❌ ERRADO: A String flutua pelo sistema e quebra a cada Typo
localStorage.setItem('user_session_token', 'abc');

// Outro componente recuperando e esbarrando numa tecla errada:
const t = localStorage.getItem('user_sesion_token'); // Vai dar null!

// ✅ CERTO: A CONSTANTE governa a String Mágica do App!
export const LOCALS_KEYS = { SESSION: 'user_session_token' };

// Todos que gravam ou leem, obedecem à fonte central:
localStorage.setItem(LOCALS_KEYS.SESSION, tk);

💡 O Porquê evitar:

Erros de digitação em Strings são impossíveis de serem "pegos" pelo compilador do Typescript. Ele confia na sua digitação! Um enum ou Objeto Constante amarra o Linter que gritará Alto na IDE se você chamar uma chave inexistente preservando o DRY.

26 / 35

DRY / Repetição - Exemplo 3 💻

Loops Manuais (Brute Forcing Lists)

O que evitar? Criar arrays "let" e ficar metendo push via "for" sem usar Funcionais.

// ❌ ERRADO: Poluindo o bloco com variáveis flutuantes para Data Parse.
let emails = [];
for (let i=0; i<users.length; i++) {
  if (users[i].active) {
     emails.push(users[i].email);
  }
}

// ✅ CERTO: Data-Driven Declarativo Puro usando os Métodos de Array!
const emails = users
  .filter(u => u.active)
  .map(u => u.email);

💡 O Porquê evitar:

Sintaxe baseada em length e i++ expõe a lógica interna desnecessariamente e afunda sua credibilidade para Seniors reescrevendo implementações pesadas de Loops For. Aproveite as High-Order Functions (HOF), filtre, altere e mapeie direto com o JS limpo!

27 / 35

Pilar 7 - Tratamento de Erros

A arte de não ser pego de surpresa na madrugada.

A teoria define: "Lidar com erros é só uma das suas preocupações, mas se atrapalhar o fluxo limpo e o entendimento, seu código está errado.".

Você não é pago apenas para escrever o "Caminho Feliz". A verdadeira robustez do Software nasce de como a Arquitetura Frontend prevê, engole e repõe a tela quando o Back-end soltar um 500 Internal Server Error. Retornar nulos silenciosos destrói debuggings futuros!

28 / 35

Tratamento Erros - Exemplo 1 💻

O "Engolidor" de Erros Silencioso (Empty Catch)

O que evitar? Jogar Erros pra debaixo do tapete que quebram o código sorrateiramente.

// ❌ ERRADO: Pelo amor de Deus, nunca dê Try Catch Vazio!
try {
  emitHeavyAnalyticsReport();
} catch (err) {
  // Deixa quieto, ninguém precisa saber que a memória estourou
}

// ✅ CERTO: Nunca silencie. Relate, Trate, Jogue pro Global Handler!
try {
  emitHeavyAnalyticsReport();
} catch (err) {
  // Manda pro Sentry, Crashlytics ou printa no Console
  Logger.error('Analytics Falhou', err);
}

💡 O Porquê evitar:

O Catch oco é o maior calcanhar de Aquiles do desenvolvimento Jr. O cliente reclamará que o botão roxo não executa nada, a QA vai abrir Bug, E você não achará erro absolutamente NENHUM em lugar algum no navegador. O Console e os Logs Varreram o crime!

29 / 35

Tratamento Erros - Exemplo 2 💻

Retornar NULL como Código de Falha

O que evitar? Retornar falsos "indefinidos" ao invés de jogar e propagar a dor real.

// ❌ ERRADO: Quem chamar isso vai bugar e não saberá o Motivo do Null!
function findUserAndFormat(id) {
  const result = db.find(id);
  if (!result) return null;
  return result;
}

// ✅ CERTO: Lançar Exceções Genuínas Explicativas (Fail Fast)
function findUserAndFormat(id) {
  const result = db.find(id);
  
  // Se quebrou a regra vital, Grite (Trate logo no Caller!)
  if (!result) throw new Error('Usuário não encontrado no banco.');
  return result;
}

💡 O Porquê evitar:

O problema em inventar status null é que o código que chamou a Função pai terá de fazer os famosos e infinitos if(user != null) para checar, e muitas vezes esquecerá, gerando a tela branca (Crash V8). Lançar Errors garante paradas forçadas ou bloqueios!

30 / 35

Tratamento Erros - Exemplo 3 💻

Callback Hells Assíncronos do Inferno

O que evitar? Sub-promises seguidos e checadores engatados manualmente de redes.

// ❌ ERRADO: Estruturas .then().catch() aninhadas infinitas de Promise
fetchApi().then((d) => {
  parseData(d).then((r) => {
     DOM.update(r);
  }).catch((e) => log(e));
}).catch((e) => logRoot(e));

// ✅ CERTO: O Try/Catch Moderno Assíncrono com Await em Linha!
async function handleDataProcess() {
  try {
    const baseData = await fetchApi();
    const response = await parseData(baseData);
    DOM.update(response);
  } catch (err) {
    // Unifica qualquer colapso da teia em 1 única barreira de falha
    ErrorHandlerService.notify(err);
  }
}

💡 O Porquê evitar:

Aninhar a arquitetura de retornos Callback gerava dívida Ciclomática monstruosa no JavaScript da década anterior. Acoplar sub-catchers torna a trilha de rede pesada. Usar `Async/Await` isola o Caminho Feliz enquanto o Bottom Level captura globalmente falhas de ambos os servidores!

31 / 35

Pilar 8 - Objetos e Dados Fixos

A imutabilidade no fluxo de informações

A teoria define: "A diferença entre Dados e Objetos é que Dados operam à mostra, enquanto Objetos operam blindando seus comportamentos internos expostos".

Quando um componente Frontend emite ou injeta Objetos brutos Javascript passando-os por "referência física", o dano interno de esbarrar sem querer em Propriedades filhas altera Globalmente até as Lists mães fora do escopo.

32 / 35

Fluxos de Dados - Exemplo 1 💻

Acessos Cegos Profundos (Cannot Read Property)

O que evitar? Crer cegamente que o Objeto que veio do JSON externo desceu íntegro.

// ❌ ERRADO: Bater na parede e dar Crash na Aplicação Frontend
function getCity(userResp) {
  // Se o backend esquecer de mandar o Address... a Tela Cai!
  return userResp.profile.address.city;
}

// ✅ CERTO: Use Fallbacks Typescripts Nativos (Optional Chaining)
function getCity(userResp) {
  // Desce macio pelo Objeto! Entregará Null limpo, e não um Crash TypeError.
  return userResp?.profile?.address?.city || 'Não Informado';
}

💡 O Porquê evitar:

Muitos Seniors gastavam horas fazendo: if(user != null && user.profile != null) para checar escopos. Assumir que redes são íntegras em 100% quebra qualquer View de usuários. O ?. (Optional Chaining) é a espada sagrada contra Erros de renderização crua no DOM.

33 / 35

Fluxos de Dados - Exemplo 2 💻

Mutações Acidentais (Side-Effects Assassinas)

O que evitar? Reescrever/Assinalar Campos de Argumentos Embutidos Recebidos pelo Pai.

// ❌ ERRADO: Você injetou o USER de Argumento e alterou ele na cara dura
function capitalizeUserLevel(user) {
  // Ao fazer =, você alterou Referências na Main Page Original também!!
  user.role = user.role.toUpperCase();
  return user;
}

// ✅ CERTO: Imutabilidade Sagrada! Desmembre e crie um CLONE Isolado.
function capitalizeUserLevel(user) {
  return {
    ...user, // Spread Clona a Carcaça Inteira Imutável
    role: user.role.toUpperCase()
  };
}

💡 O Porquê evitar:

Argumentos em JS no modo primitivo Objects fluem por RefPoint (Ponteiros de Memória Físicos). Quando você sobrescreve `user.x = y` sem clonar antes, a alteração "Vaza" de volta para todas as listas que renderizaram e deram bind daquele User antes, corrompendo a Session state inteira do Angular Data.

34 / 35

Fluxos de Dados - Exemplo 3 💻

Data Clumps e os Passadores Soltos no Frontend

O que evitar? Jogar milhares de chaves aleatórias e cruas aos Ventos para Outputs Components.

<!-- ❌ ERRADO: Deixando cada ponta e artéria visual furada. -->
<app-profile
  [userId]="usr.id"
  [userName]="usr.name"
  [userAge]="usr.age"
  [userPhoto]="usr.avatar"></app-profile>

<!-- ✅ CERTO: Trafegue Classes de Transferencia Data Models (DTOs) Agregadas -->
<app-profile [userPayload]="usr"></app-profile>

// Pelo TS, o Type garante que as artérias não engassem nas dezenas de Linhas Inputs.

💡 O Porquê evitar:

Data Clumps ocorrem quando um grupo de Primitivos Data sempre transitam misteriosamente juntos pelas assinaturas de métodos (ruído excessivo). Eles naturalmente pertencem ao mesmo Escopo Conceitual. Você precisa agrupá-los em 1 único model "UserDto". Despejar tudo como Inputs soltos gera dor.

35 / 35

Quando deixamos o código de legado assustar o time inteiro de apertar Commit achando que o servidor vai desabar...

Significa que a Régua do Clean Code não existiu. Não proteja as coisas erradas da sua equipe com remendos. Reescreva com Nomes Semânticos, Funções Puras Menores, Abstrações Positivas e Imutabilidade Sagrada!

O Segredo: Código limpo é como ler uma piada excelente. Não precisa de ninguém ali do seu lado para tentar explicá-la no fim da linha!.

Dessas Regras Pragmáticas dissecadas nos 💻 Códigos...

Qual Regra Oculta Mais Incomoda você e faz os Seniors baterem nas Paredes na sua Empresa?

Solta a voz nos comentários! 👇

CLEANCODE

O guia pragmático pros devsFrontend não passarem vergonha.

Não decore. Aprenda no Código.

CLEAN
CODE

O guia pragmático pros devs
Frontend não passarem vergonha.