---
# System prepended metadata

title: Code Review MD5 - Fron-end

---

# 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.