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
This is an old version of this page. You can view the most recent version or browse the history.

padronizacao

Home Sprints Requisitos Arquitetura Configuração Mockups Banco de Dados Instalação Deploy Gerência Time Padronização Git Workflow Qualidade

Front-End

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
});

Back-End

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