Guia de estilo do Google em C ++. Parte 1

Parte 1. Introdução
...
Parte 8. Nomeação
Parte 9. Comentários
...


Ao escrever código, todos usamos as regras de design de código. Às vezes, suas próprias regras são inventadas; em outros casos, guias de estilo prontos são usados. Embora todos os programadores de C ++ leiam em inglês mais facilmente do que em seu idioma nativo, é mais agradável ter um manual no último.
Este artigo é uma tradução de parte do guia de estilo do Google em C ++ para o russo.
Artigo original (fork no github), tradução atualizada .
Esta é a parte introdutória do guia, que aborda as questões gerais de "Por quê?"
Além disso, após a tradução, haverá várias respostas para possíveis perguntas.

Entrada

O C ++ é uma das principais linguagens de programação usadas em projetos de código aberto do Google, e sabe-se que o C ++ é uma linguagem muito poderosa. No entanto, é uma linguagem complexa e, se usada incorretamente, pode ser uma fonte de bugs, dificultando a leitura e a manutenção do código.

O objetivo deste guia é gerenciar a complexidade do código, descrevendo em detalhes como vale a pena (ou não) escrever código C ++. As regras deste guia simplificarão o gerenciamento de código e aumentarão o desempenho dos codificadores.

Estilo - convenções seguidas pelo código C ++. Estilo é mais do que formatar um arquivo com código.

A maioria dos projetos de código aberto desenvolvidos pelo Google segue este guia.

Nota: este guia não é um tutorial em C ++: pressupõe-se que você esteja familiarizado com o idioma.

Objetivos do Guia de Estilo

Por que este documento é necessário?

Existem vários objetivos principais deste documento, o Porquê interno, regras individuais subjacentes. Usando esses objetivos, você pode evitar longas discussões: por que as regras são e por que devem ser seguidas. Se você entende os objetivos de cada regra, é mais fácil concordá-los ou rejeitá-los, avaliar alternativas ao alterar as regras por si mesmo.

Os objetivos de gerenciamento são os seguintes:

• As regras devem valer a pena a mudança.
  
  
  • Os benefícios de usar um estilo único devem superar a insatisfação dos engenheiros em lembrar e usar as regras.
  • A vantagem é avaliada em comparação com a base de código sem a aplicação de regras; portanto, se seu pessoal ainda não aplicar as regras, o benefício será muito pequeno.
  • Esse princípio explica por que algumas regras estão ausentes: por exemplo, o goto viola muitos princípios, mas praticamente não é usado, portanto, o Guia não o descreve.
• Otimizado para leitura, não para escrita
  
  
  • Nossa base de código (e a maioria dos componentes individuais) será usada por um longo tempo. Portanto, significativamente mais tempo será gasto na leitura desse código do que na escrita.
  • Claramente, cuidamos que nossos engenheiros tenham um lego para ler, manter e depurar códigos. “Deixar o código de depuração / registro” é uma das conseqüências: quando um trecho de código funciona “estranhamente” (por exemplo, ao transferir a propriedade de um ponteiro), a presença de dicas de texto pode ser muito útil ( std :: unique_ptr mostra claramente a transferência de propriedade).
• Escreva um código semelhante a um existente
  
  O uso de um único estilo em uma base de código permite alternar para outros problemas mais importantes.
  
  Além disso, um único estilo promove a automação. E, é claro, o formato automático do código (ou o alinhamento de #include ) funcionará corretamente se atender aos requisitos do utilitário. Em outros casos, apenas um (o mais adequado) é usado no conjunto de regras, e alguma flexibilidade no uso das regras permite que as pessoas discutam menos.
• Escreva um código semelhante ao usado na comunidade C ++ (se possível)
  
  A consistência do nosso código com o código C ++ de outras organizações e comunidades é muito útil. Se os recursos do C ++ padrão ou os idiomas aceitos da linguagem facilitam os programas de escrita, é uma ocasião para usá-los. No entanto, às vezes o padrão e os idiomas são pouco adequados para a tarefa. Nesses casos (conforme descrito abaixo), faz sentido limitar ou proibir o uso de alguns recursos padrão. Em alguns casos, sua solução é criada, mas às vezes são usadas bibliotecas externas (em vez da biblioteca C ++ padrão) e reescrevê-la para seu próprio padrão é muito cara.
• Evite estruturas inesperadas ou perigosas.
  
  O C ++ possui abordagens não óbvias e até perigosas. Alguns estilos de codificação limitam seu uso, como seu uso acarreta grandes riscos pela correção do código.
• Evite construções que o programador C ++ médio considere abstrusas e difíceis de suportar
  
  No C ++, geralmente há recursos que não são bem-vindos devido à complexidade do código.
  No entanto, no código freqüentemente usado, o uso de construções complicadas é mais justificado devido ao uso repetido, assim como novas partes do código se tornam mais claras.
  
  Em caso de dúvida, consulte o líder do projeto.
  
  Isso é muito importante para nossa base de código, pois os proprietários do código e uma equipe de suporte mudam com o tempo: mesmo que todos entendam o código agora, as coisas podem mudar em alguns anos.
• Considere a escala do código
  
  Com uma base de código de mais de 100 milhões de linhas e milhares de engenheiros, erros e simplificações podem ser caros. Por exemplo, é importante evitar sobrecarregar o espaço para nome global: é muito difícil evitar colisões de nomes em uma grande base de código se tudo for declarado no espaço para nome global.
• Otimize conforme necessário
  
  Às vezes, a otimização do desempenho é mais importante do que seguir as regras de codificação.

A intenção deste documento é fornecer as orientações mais compreensíveis com restrições razoáveis. Como sempre, ninguém cancelou o bom senso. Com essa especificação, queremos estabelecer convenções para toda a comunidade do Google em C ++, não apenas para equipes ou pessoas individuais. Seja cético em relação a projetos astutos ou incomuns: a falta de limitação nem sempre tem uma resolução. E se você não pode decidir por si mesmo, pergunte ao chefe.

Versão C ++

Agora, o código deve estar em conformidade com o C ++ 17, ou seja, Os recursos C ++ 2x são indesejáveis. No futuro, o manual será ajustado para versões mais recentes do C ++.

Não use extensões personalizadas .

Considere a compatibilidade com outros ambientes se você pretende usar C ++ 14 e C ++ 17 em seu projeto.

Nota: Os links podem levar a seções do manual que ainda não foram traduzidas.

Algumas respostas / comentários:

- Por que transferir?

Pessoalmente, estou mais à vontade com a liderança russa. Também é melhor discutir mudanças no guia de estilo com o texto em russo.

- Por que google? Existem mais (ou menos) populares ...?

A empresa é bastante conhecida, a liderança não é muito grande (você pode traduzi-la sem esforço por uma pessoa), atende às funções necessárias - este guia é elegante

- Mas o manual do Google declara o uso de obsoleto (...), a rejeição de tão útil (...)! Porque

Pelo que entendi, este documento é uma proposta. Você vai usar alguma coisa, mudar alguma coisa - isso é permitido. Liderança é uma boa base.