Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • appoio-wiki appoio-wiki
  • Project information
    • Project information
    • Activity
    • Labels
    • Planning hierarchy
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 0
    • Issues 0
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 0
    • Merge requests 0
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • APPOIO
  • appoio-wikiappoio-wiki
  • Wiki
  • padronizacao

Last edited by Rafael Victor Ruwer Araujo Oct 16, 2020
Page history

padronizacao

Home Escopo Arquitetura Configuração Mockups BD Instalação Gerência Qualidade Processo

Padronização de código

Acesso rápido

  • Frontend
    • Nomenclatura de arquivos
    • Documentação
    • Código
  • Backend
    • Nomenclatura de arquivos
    • Classes
    • Funções e variáveis
    • Documentação

Frontend

Nomenclatura de arquivos

Na nomenclatura dos arquivos cada palavra deve ser iniciada com letra maiúscula seguida de letras minúsculas (sem espaço, underline ou hífen). Dependendo do arquivo que está sendo criado é necessário que o sua funcionalidade seja adicionada ao nome. Podemos ver melhor essa regras nos exemplos abaixo:

Components: ExemploComponent.js

Screen: ExemploScreen.js

Documentação

A documentação deve estar presente em todos os _Components e Screens criadas. A documentação será feita com JavaDoc e deverá estar localizada no topo do código, antes mesmo das importações

Os seguintes dados deverão ser utilizados nessa ordem:

  • Descrição da função do arquivo criado
  • @author Nome dos criadores do arquivo separado por vírgulas.
  • @param nome Parâmetro que o Component ou Screen precisa para ser executado (prop).
  • @example Exemplo de chamada do Component ou Screen.

O trecho de código abaixo apresenta uma exemplificação da documentação de um componente de botão simples.

/**
  * Componente de botão básico
  * 
  * @author           João Leão, Rafael Araujo e Eduardo Cardoso
  * @param name       Texto a ser exibido dentro botão
  * @param onClick    Ação a ser realizada pelo botão
  * @example          <ButtonComponent
  *                     name={"Fazer Login"} 
  *                     action={login} 
  *                   /> 
  */

Código

Depois da documentação, os códigos de Component e de Screen deve seguir a seguinte formatação:

  • Importações necessárias
  • Função necessárias
  • Função default com retorno em HTML
  • Constante da estilização do componente

O exemplo abaixo apresenta o formato que deve ser seguido. Trechos acompanhados do símbolo $ devem ser substituídos pelo código desenvolvido (a não ser que não seja necessário).

import React from 'react';
import { StyleSheet, $componentsToImport } from 'react-native';

$functions

export default function $name(props) {
  return (
    $htmlCode
  );
}

const styles = StyleSheet.create({
  $style
});

Backend

Nomenclatura de arquivos

Todos arquivos, com exceção dos "index.js", devem fazer uso do padrão PascalCase, ou seja, primeira letra de cada palavra deve ser maiúscula.

exemplo de arquivo

Classes

As classes devem ser nomeadas no singular e fazendo uso do padrão PascalCase para nomeação, ou seja, primeira letra de cada palavra deve ser maiúscula.

exemplo de classe

Funções e variáveis

As variáveis utilizadas no programa devem fazer uso do padrão camelCase para nomeação, ou seja, primeira letra minúscula e a separação das palavras é por letra maiúscula.

exemplo de código

Documentação

Fazer uso de comentários com /**/ logo acima do pedaço de código que irá ser documentado, pode incluir marcações como @example, @param, @returns, idealmente devem ser incluídas todas as marcações, mas caso não seja simples/possível deve ter ao menos @param e @returns na documentação.

exemplo documentação

Clone repository
  • Rotas
  • arquitetura
  • banco_dados
  • configuracao
  • deploy
  • escopo
  • git_workflow
  • gp
  • Home
  • instalacao
  • mockups
  • padronizacao
  • processo
  • qualidade