Quais são as diretrizes de formatação de código geralmente aceitas?

Question

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?

Answer 1

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 :-)

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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

Answer 6

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.