# Code Review MD5 - Fron-end - Estrutura de pastas/arquivos - Assets - Boa prática: - Agrupar imagens em pastas contendo as mesmas referências de usabilidade - Mau prática: - Deixar as imagens soltas dentro da pasta assets - Estruturas dos compontes - Boa prática: - Pasta com nomeclatura pascal case e arquivo index - Arquivo(s) de estilo(s), caso necessário - Mau prática: - Nomeclatura sem o padrão `PascalCase` - Fora da estrutura visto em aula (Pasta/index.js) - Estruturas das páginas - Boa prática: - Pasta com nomeclatura `PascalCase` e arquivo index - Arquivo(s) de estilo(s), caso necessário - Mau prática: - Nomeclatura sem o padrão `PascalCase` - Fora da estrutura visto em aula (Pasta/index.js) - Estrutura da Context API - Boa prática: - Criar o contexto e o hook em arquivos separados - Nomeclatura do arquivo do contexto deve ser `PascalCase` - Nomeclatura do arquivo do hook deve ser `camelCase` - O nome do hook deve iniciar com o prefixo `use` - Mau prática: - Contexto e hook unificado - Nomeclatura do arquivo do contexto fora do padrão `PascalCase` - Nomeclatura do arquivo do hook fora dp padrão `camelCase` - O nome do hook não está sendo iniciado com o prefixo `use` - Arquivo de Rotas - Boa prática: - Usar do Outlet para renderizar as páginas - Importar os contextos dentro das rotas - Ter uma rota para página não encontrada - Mau prática: - Não tem uma Função para as rotas protegidas com token - Não usar do Outlet para renderizar as páginas - Não importar os contextos dentro das rotas - Não tem uma rota para página não encontrada - Rotas protegidas - Boa prática: - Ter uma Função para as rotas protegidas com token - Mau prática: - Não tem uma Função para as rotas protegidas com token - Organização do CSS - Boa prática: - Deve conter uma pasta contendo os estilos globais da aplicação - Deve existir estilos para o design system do projeto. (EX: tema, formulário, tupografia, etc...) - Mau prática: - Não contém uma pasta contendo os estilos globais da aplicação - Não existe estilos para o design system do projeto. (EX: tema, formulário, tupografia, etc...) - Integração - Boa prática: - Deve existir uma pasta chamada services contendo as configurações de integração com axios - Mau prática: - Não existe ve existir uma pasta chamada services contendo as configurações de integração com axios - Qualidade e boas práticas - Boa prática: - Código bem indentado - Funções modularizada e componentizado - Clareza na escrita do código - Padronização na escrita do código - Tratando eventuais erros - Mau prática: - Não `indentado`: Com a indentação, o código fica bem mais limpo, legível e organizado. - Não `modularizado e Componentizado`: dividir o código em funções e métodos menores, organizados em bibliotecas, classes ou pacotes – a depender da linguagem –, faz com que o código fique mais curto, organizado e, principalmente, favorece o reaproveitamento de código. - Com vários `comentários`: Comentar é uma arte! Claro que você não precisa comentar linha a linha, pois comentários óbvios e em excesso também atrapalham a fluidez do código. - Código escrito sem `clareza`: Seu estilo de programação deve ser claro. Por exemplo, escolha nomes significativos para suas variáveis e funções, faça funções pequenas que realizem uma tarefa bem definida, evite o uso de variáveis globais, modularize seu código e estabeleça interfaces claras entre os módulos. Quem ler seu código não deve ter dificuldade para compreender o que cada trecho faz. - Código não está `padronizado`: A padronização é uma boa prática que você deve adotar quando programar sozinho, mas que será essencial quando você participar de um projeto em grupo. - Sem `tratamento de erros e exceções`: Não presuma que o usuário sempre fornecerá os dados da forma ideal ou que a máquina nunca irá se deparar com exceções. Você precisa analisar condições de erros e exceções, prevendo-as na implementação do seu código.