Quais são as diretrizes de formatação de código geralmente aceitas?
-
09-06-2019 - |
Pergunta
De acordo com Modelo de qualidade de McCall, Revisão do produto é uma das três principais perspectivas para descrever os atributos de qualidade de um produto de software.Sob a perspectiva da Revisão do Produto, manutenibilidade, a capacidade de encontrar e corrigir um defeito, é identificado como um fator-chave de qualidade que impacta a capacidade de revisar o software.
Claramente, em algum momento do processo de revisão, há necessidade de envolvimento humano, especificamente envolvimento dos programadores.A formatação do código tem impacto na capacidade do programador de revisar o software de forma eficaz e eficiente.
Com quais diretrizes de formatação de código geralmente aceitas e independentes de linguagem você trabalhou para maximizar a eficiência e eficácia do programador no processo de revisão de código?
Solução
As melhores diretrizes com as quais já trabalhei são a consistência.Ao longo dos anos usei muitos estilos diferentes com equipes diferentes...os melhores resultados que vi são quando toda a equipe é forçada a usar o mesmo estilo, independente de qual estilo seja :-)
Outras dicas
Tenho algumas reflexões sobre alguns conceitos independentes de linguagem:
1.) Remova o código morto.A menos que algo seja absolutamente essencial, o código morto comentado deve ser removido.Isso atrapalha a rotina, muitas vezes você obtém falsos positivos ao procurar alguma string e mostra um desleixo geral que não é bom para um desenvolvedor profissional
2.) Para correções de manutenção, faça referência a um número de rastreamento de defeitos em um comentário - supondo que você tenha algum tipo de sistema de rastreamento de defeitos.Isso torna mais fácil para quem mantém seu trabalho descobrir por que o código foi alterado entre uma revisão e outra.
3.) Para linguagens que o suportam, declare variáveis o mais próximo possível de seu primeiro uso.
Tenho certeza de que existem alguns outros conceitos independentes de linguagem, mas esses são os primeiros que vêm à mente.Pelo que eu sei, é relativamente difícil discutir padrões de codificação na ausência de uma linguagem específica.E concordo com as outras respostas acima – o melhor estilo geralmente é aquele que combina melhor com o estilo existente.
Você pode querer dar uma olhada no livro de Steve McConnell Código completo.Está cheio de boas ideias que devem ser aplicáveis em quase todas as situações de desenvolvimento, independentemente da linguagem de programação.
Consistência é a chave.Anote as diretrizes em algum lugar e exija conformidade.
Não vale a pena se preocupar com a formatação do código, nem discutir sobre isso.Basta estabelecer algumas regras e cumpri-las.
Concordo com Joel.Existem muitos exemplos de estilo por aí;a maioria é boa.Alguns não são mais tão úteis quanto outros (notação húngara?).A questão toda é consistência, no entanto.Contanto que um novo desenvolvedor possa entrar e entender o código imediatamente, em vez de ter que se acostumar com o estilo pessoal de cada desenvolvedor, ele funciona.
Mudar de padrão a cada ano é provavelmente uma má ideia.
Concordo com Joel, a capacidade de manutenção aumenta consideravelmente quando você tem consistência dentro da sua organização.Se eu me juntar a outra equipe, o tempo de aceleração será muito menor se tudo tiver uma aparência semelhante à minha atual, porque posso ler o código muito mais rápido sem toda a "mudança de contexto interno" para entender "para que eles usem mVar em vez de _var"/etc
Um dos grandes padrões que temos é o "prefixo" de variáveis.Até chegar aqui, eu escrevia principalmente solo, então não me preocupei com isso.
Somos “obrigados” a nomear variáveis com prefixos que indiquem o que são.Então, você sabe instantaneamente, ao olhar para dpVarName, que é um ponteiro para um duplo e que lVarName é um int longo.
Fiquei feliz no início porque eles nos deram duas opções para blocos de colchetes, mas agora gostaria que todos fôssemos forçados a fazer isso de uma forma ou de outra.