Skip to main content

Padrões de Código e Nomenclatura

Este guia estabelece os padrões de nomenclatura, estilo e organização de código adotados pelo time de frontend da Smart NX (SNX). Seu objetivo é garantir clareza, consistência e manutenibilidade, permitindo que qualquer desenvolvedor leia, compreenda e evolua o código de forma previsível e produtiva.

Estes padrões se aplicam a todo o código do projeto NX Suite Frontend, incluindo componentes, hooks, serviços, contextos e testes.


Princípios Gerais​

  1. Código deve ser autoexplicativo. Evite a necessidade de comentários descritivos — nomes e estrutura devem comunicar propósito.

  2. A legibilidade é mais importante que a concisão. Código “limpo” é aquele fácil de entender, não o mais curto.

  3. Consistência acima da preferência. Mesmo quando houver várias formas válidas de fazer algo, siga o padrão do projeto.

  4. Evite duplicação. Prefira abstrair e reutilizar quando padrões se repetirem.


Nomenclatura​

Importância da Nomenclatura Consistente​

  • Legibilidade: nomes claros reduzem tempo de interpretação.
  • Manutenção: facilita revisões e refatorações.
  • Integração: mantém coerência entre múltiplos módulos e equipes.

Padrões de Nomenclatura​

CategoriaConvençãoExemploObservações
Variáveis e FunçõescamelCaseuserName, fetchUserData()Curto, direto e descritivo.
Componentes ReactPascalCaseUserProfile, DashboardCardDeve refletir o papel sem abreviações.
Interfaces e TiposI para interface / T para tipoIUser, TStatus, TChannelTypeUse prefixos obrigatórios I ou T.
EnumsPascalCaseUserRoleEnum, StatusEnumValores em UPPER_SNAKE_CASE.
ConstantesUPPER_SNAKE_CASEDEFAULT_TIMEOUT, MAX_RETRIESValores imutáveis globais.
Hooksuse + PascalCaseuseAuth, usePagination, useFormValidationSempre prefixados com “use”.
Arquivos e DiretórioscamelCaseuserProfile, authService, dateHelpersReflete o conteúdo, sem espaços ou hífens.
EstilosNome do componente + .style.tsButton.style.ts, Header.style.tsFacilita rastreabilidade.

Boas Práticas de Nomeação​

Use nomes descritivos e intencionais

// Bom
const userName = 'John Doe';
const fetchUserData = async () => {};

// Ruim
const n = 'John Doe';
const fchUsrData = async () => {};

Seja explícito no propósito

// Bom
interface IUserProps {
userId: string;
displayName: string;
}

// Ruim
interface Props {
id: string;
name: string;
}

✅ Evite contexto redundante

// Ruim — o nome já contém o contexto
const userUserName = "John";

Prefira nomes que expressem intenção

// Bom
const isAuthenticated = true;
const shouldRenderModal = false;

Princípios de Código Limpo​

Em React + TypeScript​

  1. Funções pequenas e focadas Cada função deve ter apenas uma responsabilidade. Evite funções que fazem múltiplas coisas (ex: buscam dados e atualizam estado).

  2. Componentização inteligente Prefira componentes menores e reutilizáveis. Se um componente cresce demais, extraia subcomponentes coesos.

  3. Separação de responsabilidades

    • UI (View): JSX, estilização e layout.
    • Lógica (Hooks): estado e comportamento.
    • Dados (Services): chamadas de API e integrações.
  4. Evite “componentes mágicos” Comportamentos implícitos e múltiplos efeitos colaterais tornam o código frágil.

  5. Utilize tipagem forte sempre que possível Tipos claros tornam o código previsível e reduzem erros.


Exemplo de Código Limpo​

const useUserDetails = (userId: string) => {
const [user, setUser] = useState<IUser | null>(null);

useEffect(() => {
async function fetchUser() {
const response = await fetch(`/api/users/${userId}`);
const userData: IUser = await response.json();
setUser(userData);
}

fetchUser();
}, [userId]);

return user;
};

Por que é limpo?

  • Nome descritivo (useUserDetails).
  • Única responsabilidade (buscar e armazenar dados).
  • Tipagem explícita (User | null).
  • Nenhuma lógica acoplada à UI.

Organização de Código em Componentes React​

Para maximizar legibilidade e previsibilidade, siga esta ordem interna dentro de cada arquivo .tsx:

Ordem Recomendada​

  1. Importações

    • Bibliotecas externas
    • Importações internas (contextos, hooks, componentes)
    • Estilos (último bloco de importação)
  2. Tipos e Interfaces

    • Props, estados e contextos específicos do componente
  3. Constantes Locais

    • Configurações, labels e valores fixos usados no componente
  4. Componente Principal

    • Declaração de estado e refs
    • Hooks de efeito (useEffect)
    • Callbacks (useCallback)
    • Lógicas derivadas (useMemo, useContext)
    • Render helpers
    • JSX final (return)

Exemplo Prático​

import React, { useState, useEffect, useCallback } from 'react';

interface IUserProps {
userId: number;
}

const UserProfile: React.FC<IUserProps> = ({ userId }) => {
const [user, setUser] = useState<IUser | null>(null);

useEffect(() => {
async function fetchUser() {
const response = await fetch(`/api/users/${userId}`);
const data: IUser = await response.json();
setUser(data);
}

fetchUser();
}, [userId]);

const handleUpdate = useCallback(() => {
console.log('Updating user...');
}, []);

return (
<div>
<h1>{user?.name}</h1>
<button onClick={handleUpdate}>Update</button>
</div>
);
};

export default UserProfile;

Características desejadas:

  • Importações organizadas.
  • Interface no topo do arquivo.
  • Lógica de efeitos separada do JSX.
  • JSX limpo e direto, sem lógica desnecessária inline.

Convenções Complementares​

  • Imports absolutos: use aliases definidos em tsconfig.json (@components, @hooks, etc.).
  • Separação por responsabilidades: cada arquivo deve ter um propósito claro.
  • Evite comentários redundantes: o nome do código deve explicar o que ele faz.
  • Prefira composição à herança: estenda comportamentos combinando componentes e hooks.
  • Aplique ESLint + Biome: mantenha formatação e linting automáticos padronizados.

Conclusão​

Manter um padrão de nomenclatura clara e organização coerente é essencial para a qualidade e longevidade do código. Essas práticas facilitam o trabalho em equipe, reduzem o tempo de revisão e permitem que o projeto cresça sem perder legibilidade.

A clareza é o primeiro sinal de um sistema saudável.


Histórico de Versões​

DataVersãoAutor / RevisorAlterações
08/04/2026v1.1.0Juathan Coelho DuartePadronização de prefixos I/T e atualização do guia
29/10/2025v1.0.0@Matheus TellesCriação inicial e estrutura base do documento