Discussão entre o revisor e o codificador é sadio, favorece troca de idéias e a aquisição de novos conhecimentos; Caso haja conflito, um segundo revisor pode ser acionado.
Padronização devem ser seguidos para manter organização, diminuir a curvatura de aprendizagem e legibilidade, seguem os padrões para cada tecnologia utilizada na stack.
https://github.com/johnpapa/angular-styleguide/blob/master/a1/i18n/pt-BR.md
https://github.com/airbnb/javascript/tree/es5-deprecated/es5
https://google.github.io/styleguide/javaguide.html
- Regras de negócio não devem encontrar na camada de controle, e sim na camada de domínio (Considerando aqui uma arquitetura multi camadas).
- Exceções que podem ser utilizadas mas obrigatoriamente se enquadra no "amplamente conhecido":
- Índices = i, j, k, ...
- Amplamente conhecida: HTML, XML, ...
- Siglas do domínio da aplicação: FPO, PPI, SADT, SUS, ...
- Principal item a ser considerado é o SRP (Single Responsability Principle), porém alguns itens secundários são recomendáveis:
- Complexidade ciclomática <= 10.
- Métodos menores que 30 linhas, geralmente métodos grandes violam o SRP devem ser quebrados por subtarefas, manter o mesmo nível de abstração é algo a ser considerado.
- Estruturas de controle aninhada acima de 3.
- Validar dados de entrada, checando se o comportamento do input é o esperado para a execução da tarefa (Mesmo as entradas do tipo "impossível de acontecer").
- Evite retornar null, se retornar, a avaliação do null deve ser checado como retorno.
- Caso necessário, valide a pós condição.
- Single responsibility principle
- Open/closed principle
- Liskov substitution principle
- Interface segregation principle
- Dependency inversion principle