Nav Serviços de Pagam… /
Compartilhar
Convenções de Desenvolvimento
Gerais
Criado por Mateus Macedo Dos Anjos
28/set/2021 • 10 pessoas visualizaram
Geral
Número de linguagens por arquivo - Buscar minimizar o número de
linguagens por arquivo.
O óbvio não foi implementado - Por exemplo, espera-se que uma função
denominada searchNameInNameList(name) consiga buscar um nome em
uma lista de nomes independentemente do nome estar em caixa alta/baixa
e com espaços, ou seja, esse tratamento ser feito dentro da função.
Comportamento incorreto em valores-limite - Buscar validar todas as
possibilidades.
Ignorar avisos - Ignorar avisos do compilador, linter, casos de teste que
falharam e sobrescrever trechos de código sem o devido cuidado podem
provocar erros critícos ao seu sistema.
Duplicação - Ao encontrar uma duplicação, buscar abstrair o código.
Separação de responsabilidades - Evitar misturar implementação de baixo
nível com a de alto nível.
Classes base dependendo de suas derivadas - A classe base não deve saber
detalhes de implementação de suas derivadas. Uma exceção é quando a
classe base tem que selecionar uma entre várias derivadas.
Muita informação - Minimize o quanto for possível o número de funções,
variáveis, constantes por classe.
Código morto - Descarte códigos que nunca são executados, como por
exemplo, em caso de uma condição que nunca que é atingida, ou um catch
que faz parte de um bloco que não possui um throw.
Separação vertical - Variáveis e funções devem ser definidas próximas de
onde são utilizadas. Variáveis locais devem ser declaradas logo acima do seu
primeiro uso, enquanto que funções devem estar logo abaixo do seu
primeiro uso.
Inconsistências - Busque ser consistente em nomes, lógica de métodos,
arquiteturas, etc.
Ruído - Remova códigos inutilizados como variáveis que não são utilizadas,
funções que não são chamadas, comentários que não agregam informação,
etc.
Acoplamento artificial - Coisas que não dependem uma da outra não devem
estar acopladas.
Inveja de funcionalidade - Evite acessar em uma classe detalhes de outra
classe.
Seletores de comportamento - Evite passar como argumento de uma função
um fator que determine o comportamento de uma função. Por exemplo:
É preferível criar uma função para cada comportamento:
Intuito obscuro - Evite abreviações e números mágicos.
Responsabilidade mal colocada - o código deve ser colocado onde o leitor
espera que ele esteja.
Funções que não deveriam ser estáticas - Defina como estática função em
que há certeza de que ela não terá comportamentos diferentes para objetos
diferentes.
Variáveis explicativas - Crie variáveis para valores temporários. Ou seja, ao
invés de:
Nomes de funções devem dizer o que elas fazem - O nome de uma função
deve ser suficiente para deduzir que tipo de informação deve ser passada
como parâmetro, o seu propósito e quais os argumentos de saída, caso
existam.
Se você precisa olhar a documentação/implementação para entender o que uma
função faz, essa função precisa de um nome melhor, ou ser refatorada para ter
um nome melhor.
Entenda o algoritmo antes de finalizar o desenvolvimento - Apenas passar
nos testes não é suficiente.
Torne físicas dependências lógicas - Quando um módulo depende do outro,
é importante que esse módulo explicitamente solicite esse módulo todas as
informações que ele depende.
Prefira polimorfismo ao invés de if/else e switches - Na maioria das vezes é
possível dividir responsabilidades e modularizar o código, para não utilizar
essas duas ferramentas.
Siga convenções - É importante que seu time siga o mesmo padrão.
Substitua números mágicos por constantes nomeadas
Seja preciso
Priorize estruturas de dados ao invés de convenções - Por exemplo, ao invés
de usar um switch/case bem escrito para definir o comportamento de uma
função de acordo com um enum, crie uma classe com métodos abstratos
para realizar essa função.
Encapsulamento de condicionais - Evite a combinação de operadores lógicos
com chamadas de funções em if/while. É preferível, nesses casos, encapsular
o condicional em uma função:
Evite negações em condicionais - Por exemplo:
Funções devem fazer apenas uma coisa
Acoplamentos temporais ocultos - Se uma sequência de funções tem uma
ordem a ser seguida, deixe claro qual ordem é essa. Uma forma de fazer isso
é implementar as funções de forma que cada uma retorne um resultado que
a próxima função precisa.
Tome decisões com base em fatos - Evite tomar decisões por acaso.
Encapsule condições de contorno
Funções devem conter apenas um nível de abstração
Mantenha dados de configuração em arquivos de alto nível
Evite navegação transitiva entre módulos - Se o módulo A colabora com B, e
B colabora com C, A não deveria usar módulos de C.
Modularização de blocos - É preferível que blocos dentro de
if/else/while/for tenha 1 ou 2 linhas Criar uma função para cada bloco se
if/else/while/for, tenha 1 ou 2 linhas. Criar uma função para cada bloco se
necessário. Isso também se aplica para encadeamentos, os quais não
deveriam conter níveis maiores do que 2.
Priorizar try/catch para tratativas de erros - É importante que blocos de
try/catch tenham suas próprias funções.
Use exceções - Use exceções ao invés de retornar códigos de erro. Cada
exceção deve fornecer informações suficientes para determinar a fonte e a
localização do erro.
Evite retornar/enviar null
Curtir Seja o primeiro a curtir isso Nenhum rótulo
