Mudanças entre as edições de "Padrão de Desenvolvimento - Codificação"

De Redome
Ir para: navegação, pesquisa
(Criou página com 'Convenções de codificação para o desenvolvimento do backend (Java) e frontend (Angular) do sistema Redome. Esse padrão define as regras de como o código-fonte deve ser e...')
 
Linha 1: Linha 1:
 +
[[Padrões de Desenvolvimento|'''Voltar''']]
 +
<br/><br/>
 
Convenções de codificação para o desenvolvimento do backend (Java) e frontend (Angular) do sistema Redome. Esse padrão define as regras de como o código-fonte deve ser escrito.
 
Convenções de codificação para o desenvolvimento do backend (Java) e frontend (Angular) do sistema Redome. Esse padrão define as regras de como o código-fonte deve ser escrito.
 
== '''Backend - Linguagem de Programação Java''' ==
 
== '''Backend - Linguagem de Programação Java''' ==

Edição das 14h37min de 4 de maio de 2021

Voltar

Convenções de codificação para o desenvolvimento do backend (Java) e frontend (Angular) do sistema Redome. Esse padrão define as regras de como o código-fonte deve ser escrito.

Backend - Linguagem de Programação Java

ENCODING

Os arquivos deverão estar em UTF-8.

NOMECLATURA

REGRAS GERAIS

Os identificadores deverão utilizar somente letras e números. Será utilizado o português, exceto para os métodos oriundos de uma API, como o Spring Data.

PACKAGE

Deverão conter apenas letras minúsculas.

CLASSES

Deverão ter seus nomes em formato UpperCamelCase e ser um substantivo.

MÉTODOS

Deverão ter seus nomes em formato LowerCamelCase. Deve iniciar com um verbo no infinitivo, exemplo: listar, salvar, obter.

Utilizaremos o prefixo "listar" para métodos que retornarão uma coleção de registros, "obter" para métodos que retornarão apenas um registro.

Utilizaremos "salvar", "excluir" e "atualizar" como nome dos métodos que efetuam alguma operação com um registro.

CONSTANTES

Deverão ter seus nomes em letra maiúscula com as palavras separadas com underline.

PARÂMETROS, PROPRIEDADES E VARIÁVEIS LOCAIS

Deverão ter seus nomes em formato LowerCamelCase.


ESTILO

QUEBRA DE LINHA

O tamanho máximo da linha será de 100 caracteres.

As linhas serão quebradas quando ultrapassarem o tamanho máximo e serão indentadas adicionando mais 2 espaços.

Após a declaração de annotations em packages, classes, interfaces, enum, propriedades, métodos e variáveis locais deve existir uma quebra de linha.

Cada comando deve ser seguido por uma quebra de linha.

Também deve existir um quebra de linha antes do ‘else’, ‘catch’, ‘finnaly’ e ‘while’ em um comando do, conforme imagem abaixo:

Exemplo-estilo-codigo-java.png

Declarações de imports, packages e tipos parametrizados não devem ser quebrados.

INDENTAÇÃO

A indentação padrão será de 4 espaços.

Serão indentados:

  • Declarações dentro do corpo das classes;
  • Declarações dentro das definições dos enums e suas constantes;
  • Declarações dentro das definições de annotations;
  • Corpo dos métodos e construtores;
  • Corpo dos switch e case.
  • Break;

Linhas vazias não serão indentadas;

CHAVES

Blocos if, for, switch e while que possuem ao menos um comando no seu corpo devem abrir e fechar chaves.

As seguintes declarações terão a abertura da chave na mesma linha do seu inicio:

  • Classes ou interfaces;
  • Classes anônimas;
  • Construtores;
  • Métodos;
  • Enums;
  • Constantes do Enum;
  • Annotation type;
  • Blocos em geral;

A abertura da chave na inicialização de arrays e lambda somente irá para a próxima linha em caso de quebra.

PARÊNTESES

Os parênteses sempre abrem na mesma linha do inicio do comando.

ADIÇÃO DE LINHAS

Será adicionada uma linha em branco:

  • Após a declaração dos packages;
  • Antes e depois das declarações de imports;
  • Entre os diferentes grupos de imports;
  • Entre as declarações das classes;
  • Antes da primeira declaração do corpo da classe;
  • Antes da declaração de membros das classes;
  • Antes da declaração dos métodos;

ORDENAÇÃO DOS ELEMENTOS

  1. Licença ou copyright;
  2. Packages;
  3. Static Imports;
  4. Non-static imports;
  5. Comentários sobre a classe, interface ou enum;
  6. Declaração da classe, interface ou enum;
  7. Propriedades estáticas na seguinte ordem: public, protected, package e private;
  8. Propriedades da instância na seguinte ordem: public, protected, package e private;
  9. Construtores;
  10. Métodos getters e setters;
  11. Outros métodos agrupados por funcionalidade;
  12. Métodos sobrescritos da classe Object;

PRÁTICAS DE PROGRAMAÇÃO

MODIFICADORES

Os modificadores deverão ser ordenados conforme a especificação da linguagem:

public protected private abstract default static final transient volatile synchronized native strictfp

 

OVERRIDE

Sempre utilize o @Override, exceto se o método pai estiver @Deprecated.

IGNORANDO UMA EXCEPTION

Ao ignorar uma exception numa claúsula catch, adicione um comentário com o motivo

Exemplo-estilo-ignorar-exception-java.png

MEMBRO ESTÁTICO

Ao referenciar um membro estático de uma classe, sempre utilize o nome da classe.

Exemplo-estilo-membro-estatico-java.png

PARÊNTESES

Sempre é uma boa ideia usar parênteses para separar expressões com operadores mistos para evitar problemas de leitura e de precedência.

Exemplo:

 if (a == b && c == d)     // AVOID!
 if ((a == b) && (c == d)) // RIGHT

Também é uma boa ideia usar parênteses em operações com o operador ternário, onde a condição utiliza um operador binário.

Exemplo:

(x >= 0) ? x : -x;

 

RETORNANDO VALORES

Faça com que a estrutura do seu código demonstre a sua intenção.

Invés de:

if (booleanExpression) {
   return true;
} else {
   return false;
}

Escreva dessa maneira:

return booleanExpression;


Assim como:

if (condition) {
   return x;
}
return y;

Deveria ser:

return (condition ? x : y);


FINALIZE

Nunca sobrescreva o método Object.finalize().


Frontend - Linguagem de Programação Angular 2

O frontend do sistema Redome segue o padrão de codificação para a criação/manutenção de aplicações em angular 2 disponível no seguinte endereço:

https://angular.io/styleguide