Diretrizes para melhorar seu código

Question

Que diretrizes você segue para melhorar a qualidade geral do seu código?Muitas pessoas têm regras sobre como escrever código C++ que (supostamente) tornam mais difícil cometer erros.Eu vi pessoas insistir que cada if instrução é seguida por um bloco de chaves ({...}).

Estou interessado nas diretrizes que outras pessoas seguem e nas razões por trás delas.Também estou interessado em diretrizes que você considera uma porcaria, mas que são comumente aceitas.Alguém pode sugerir alguns?

Para dar o pontapé inicial, mencionarei alguns para começar:

• Sempre use aparelho após cada if / else declaração (mencionada acima).A razão por trás disso é que nem sempre é fácil saber se uma única instrução é na verdade uma instrução ou uma macro de pré-processador que se expande para mais de uma instrução, portanto este código quebraria:

    // top of file:
    #define statement doSomething(); doSomethingElse

    // in implementation:
    if (somecondition)
        doSomething();

mas se você usar aparelho, funcionará conforme o esperado.

• Use macros de pré-processador SOMENTE para compilação condicional.macros de pré-processador podem causar todo tipo de problema, já que não permitem regras de escopo C++.Já encalhei muitas vezes devido a macros de pré-processador com nomes comuns em arquivos de cabeçalho.Se você não tomar cuidado você pode causar todo tipo de estrago!

Agora é com você.

Answer 1

Alguns dos meus favoritos pessoais:

Esforce-se para escrever um código que seja const correto.Você contratará o compilador para ajudar a eliminar bugs fáceis de corrigir, mas às vezes dolorosos.Seu código também contará uma história sobre o que você tinha em mente no momento em que o escreveu – valioso para novatos ou mantenedores quando você partir.

Saia do negócio de gerenciamento de memória.Aprenda a usar ponteiros inteligentes: std::auto_ptr, std::tr1::shared_ptr (ou boost::shared_ptr) e boost::scoped_ptr.Aprenda as diferenças entre eles e quando usar um vs.outro.

Você provavelmente usará a biblioteca de modelos padrão.Leia o Livro de Josutti.Não pare depois dos primeiros capítulos sobre containers pensando que você conhece o STL.Vá direto para as coisas boas:algoritmos e objetos de função.

Answer 2

1. Exclua o código desnecessário.

Isso é tudo.

Answer 3

• Use e aplique um estilo e diretrizes de codificação comuns. Justificativa: Cada desenvolvedor da equipe ou da empresa é capaz de ler o código sem distrações que podem ocorrer devido a diferentes estilos de chaves ou similares.
• Faça regularmente uma reconstrução completa de toda a sua base de origem (ou seja,faça compilações diárias ou compilações após cada check-in) e relate quaisquer erros! Justificativa: A fonte está quase sempre em estado utilizável e os problemas são detectados logo após serem "implementados", onde a solução do problema é barata.

Answer 4

Ative todos os avisos que você puder ter em seu compilador (gcc: -Wall é um bom começo, mas não inclui tudo, então verifique a documentação) e cometa erros para corrigi-los (gcc: -Werror).

Answer 5

O guia de estilo do Google, mencionado em uma dessas respostas, é bastante sólido.Há algumas coisas inúteis nisso, mas é mais bom do que ruim.

Sutter e Alexandrescu escreveram um livro decente sobre esse assunto, chamado Padrões de codificação C++.

Aqui estão algumas dicas gerais de mim:

1. Seu estilo de recuo e colchetes estão errados.O mesmo acontece com todos os outros.Portanto siga as normas do projeto para isso.Engula seu orgulho e configure seu editor para que tudo fique o mais consistente possível com o resto da base de código.É realmente muito chato ter que ler código recuado de forma inconsistente.Dito isto, o bracketing e o recuo não têm nada a ver com "melhorar seu código". É mais sobre melhorar sua capacidade de trabalhar com outras pessoas.

2. Comente bem.Isto é extremamente subjetivo, mas em geral é sempre bom escrever comentários sobre por que o código funciona da maneira que funciona, em vez de explicar o que faz.É claro que para códigos complexos também é bom para programadores que talvez não estejam familiarizados com o algoritmo ou código terem uma ideia do o que está indo bem.Links para descrições dos algoritmos empregados são muito bem-vindos.

3. Expresse a lógica da maneira mais direta possível.Ironicamente, sugestões como "colocar constantes no lado esquerdo das comparações" deram errado aqui, eu acho.Eles são muito populares, mas para quem fala inglês, muitas vezes quebram o fluxo lógico do programa para quem está lendo.Se você não pode confiar em si mesmo (ou em seu compilador) para escrever comparações de igualdade corretamente, use truques como este.Mas você está sacrificando a clareza ao fazer isso.Também se enquadram nesta categoria coisas como ..."Minha lógica tem 3 níveis de indentação?Poderia ser mais simples?" e transformar código semelhante em funções.Talvez até dividindo funções.É preciso experiência para escrever código que expresse elegantemente a lógica subjacente, mas vale a pena trabalhar nisso.

Esses eram bastante gerais.Para dicas específicas, não consigo fazer um trabalho muito melhor do que Sutter e Alexandrescu.

Answer 6

Nas instruções if, coloque a constante à esquerda, ou seja,

if( 12 == var )

não

if( var == 12 )

Porque se você deixar de digitar '=', isso se tornará uma tarefa.Na versão superior o compilador diz que isso não é possível, na última ele roda e o if é sempre verdadeiro.

Eu uso colchetes para if sempre que eles não estão na mesma linha.

if( a == b ) something();
if( b == d )
{
    bigLongStringOfStuffThatWontFitOnASingleLineNeatly();
}

Os colchetes abertos e fechados sempre têm suas próprias linhas.Mas isso é obviamente uma convenção pessoal.

Answer 7

Comente apenas quando for necessário apenas explicar o que o código está fazendo, onde a leitura do código não poderia lhe dizer o mesmo.

Não comente o código que você não está mais usando.Se você deseja recuperar código antigo, use seu sistema de controle de origem.Comentar o código apenas faz com que as coisas pareçam confusas e faz com que seus comentários que realmente são importantes desapareçam na bagunça de fundo do código comentado.

Answer 8

1. Use formatação consistente.
2. Ao trabalhar em código legado, utilize o estilo de formatação existente, especialmente.estilo de cinta.
3. Obtenha uma cópia do livro Effective C++ de Scott Meyer
4. Obtenha uma cópia do livro Code Complete de Steve MConnell.

Answer 9

Há também um bom Guia de estilo C++ usado internamente pelo Google, que inclui a maioria das regras mencionadas aqui.

Answer 10

Comece a escrever muitos comentários - mas use isso como uma oportunidade para refatorar o código para que seja autoexplicativo.

ou seja:

for(int i=0; i<=arr.length; i++) {
  arr[i].conf() //confirm that every username doesn't contain invalid characters
}

Deveria ter sido algo mais parecido

for(int i=0; i<=activeusers.length; i++) {
  activeusers[i].UsernameStripInvalidChars()
}

Answer 11

• Use as guias para recortes, mas alinhe dados com espaços, isso significa que as pessoas podem decidir quanto recuar alterando o tamanho da guia, mas também que as coisas permanecem alinhadas (por exemplo, você pode querer todo o '=' em uma linha vertical ao atribuir valores a um estrutura)

• Sempre use constantes ou funções embutidas em vez de macros quando possível

• Nunca use 'using' em arquivos de cabeçalho, porque tudo que inclui esse heafer também será afetado, mesmo que a pessoa que inclui seu cabeçalho não queira todo o std (por exemplo) em seu namespace global.

• Se algo tiver mais de 80 colunas, divida-o em várias linhas, por exemplo

  if(SomeVeryLongVaribleName != LongFunction(AnotherVarible, AString) &&
     BigVaribleIsValid(SomeVeryLongVaribleName))
  {
      DoSomething();
  }
  

• Apenas sobrecarregue os operadores para fazê-los fazer o que o usuário espera, por exemplo, sobrecarregar os operadores + e - para um 2dVector é aceitável

• Sempre comente seu código, mesmo que seja apenas para dizer o que o próximo bloco está fazendo (por exemplo, "exclua todas as texturas que não são necessárias para este nível").Alguém pode precisar trabalhar com isso mais tarde, possivelmente depois que você sair e não quiser encontrar milhares de linhas de código sem comentários para indicar o que está fazendo o quê.

Answer 12

1. configure a convenção de codificação e faça com que todos os envolvidos sigam a convenção (você não gostaria de ler código que exija que você descubra onde está a próxima instrução/expressão porque ela não está recuada corretamente)
2. refatorar constantemente seu código (obtenha uma cópia de Refactoring, de Martin Fowler, prós e contras são detalhados no livro)
3. escrever código fracamente acoplado (evite escrever comentários escrevendo código autoexplicativo, código fracamente acoplado tende a ser mais fácil de gerenciar/adaptar-se às alterações)
4. se possível, teste a unidade do seu código (ou se você for macho o suficiente, TDD).
5. libere cedo, libere frequentemente
6. evite otimização prematura (a criação de perfil ajuda na otimização)

Answer 13

Na mesma linha, você pode encontrar algumas sugestões úteis aqui: Como você faz o código errado parecer errado?Que padrões você usa para evitar erros semânticos?

Answer 14

Sempre que possível, use pré-incremento em vez de pós-incremento.

Answer 15

Eu uso o PC-Lint em meus projetos C++ e gosto especialmente de como ele faz referência a publicações existentes, como as diretrizes MISRA ou "Effective C++" e "More Effective C++" de Scott Meyers.Mesmo se você estiver planejando escrever justificativas muito detalhadas para cada regra que sua ferramenta de análise estática verifica, é uma boa ideia apontar para publicações estabelecidas nas quais seu usuário confia.

Answer 16

Aqui está o conselho mais importante que recebi de um guru de C++ e que me ajudou em algumas ocasiões críticas a encontrar bugs em meu código:

• Use métodos const quando um método for não é suposto para modificar o objeto.
• Use referências const e ponteiros em parâmetros quando o objeto for não é suposto para modificar o objeto.

Com essas 2 regras, o compilador lhe dirá gratuitamente onde a lógica está falha no seu código!

Answer 17

Além disso, para algumas boas técnicas que você pode seguir Blog do Google "Testando no banheiro".

Answer 18

Veja seis meses depois

Answer 19

certifique-se de recuar corretamente

Answer 20

Hmm - eu provavelmente deveria ter sido um pouco mais específico.

Não estou procurando conselhos para mim mesmo - estou escrevendo uma ferramenta de análise de código estático (as ofertas comerciais atuais simplesmente não são boas o suficiente para o que desejo) e estou procurando ideias de plug-ins para destacar possíveis erros no código.

Várias pessoas mencionaram coisas como correção const e uso de ponteiros inteligentes - esse é o tipo de coisa que posso verificar.Verificar recuo e comentários é um pouco mais difícil de fazer (pelo menos do ponto de vista da programação).

Answer 21

Os ponteiros inteligentes têm uma ótima maneira de indicar a propriedade com muita clareza.Se você é uma classe ou função:

• se você conseguir um ponteiro bruto, você não possui nada.Você está autorizado a usar a ponta, cortesia de seu chamador, que garante que a ponta permanecerá viva por mais tempo que você.
• se você conseguir um fraco_ptr, você não é o dono da ponta e, além disso, a ponta pode desaparecer a qualquer momento.
• se você conseguir um compartilhado_ptr, você possui o objeto junto com outros, então não precisa se preocupar.Menos estresse, mas também menos controle.
• se você conseguir um auto_ptr, você é o único proprietário do objeto.É seu, você é o rei.Você tem o poder de destruir esse objeto ou entregá-lo a outra pessoa (perdendo assim a propriedade).

Acho o caso de auto_ptr particularmente forte:em um design, se eu vir um auto_ptr, sei imediatamente que esse objeto irá "vagar" de uma parte do sistema para outra.

Essa é pelo menos a lógica que uso no meu projeto favorito.Não tenho certeza de quantas variações podem existir sobre o assunto, mas até agora esse conjunto de regras me serviu bem.