Código C++ que não é vergonha mostrar aos colegas: code style e convenções

Quando "funciona" não é o principal

Imagine a situação: você abre um pull request de outra pessoa em C++. O código compila, os testes passam, a lógica está correta. Mas você gasta 40 minutos para entender o que está acontecendo. As variáveis são chamadas de a, b, ptr2, a indentação varia de 2 a 8 espaços, e em um único arquivo se misturam snake_case e camelCase. Familiar?

No desenvolvimento individual, esse caos ainda pode ser tolerado. Mas assim que um segundo, terceiro ou décimo desenvolvedor entra no projeto, a falta de um code style C++ unificado transforma o código em um "pântano". Cada um escreve como está acostumado, e o tempo gasto em code review cresce exponencialmente.

Neste artigo, vamos abordar quais convenções C++ realmente funcionam em equipe, como implementá-las sem dor e por que isso economizará seus nervos e dinheiro. Vamos lá!

Por que code style não é sobre "ficar bonito", mas sobre dinheiro

Muitos pensam que discussões sobre estilo de código são perda de tempo. Na prática, pesquisas (por exemplo, do Google e da Microsoft) mostram que: a legibilidade do código afeta diretamente o número de bugs. Quando um desenvolvedor gasta menos esforço para decifrar o que foi escrito, ele comete menos erros durante a refatoração e encontra problemas mais rapidamente.

Um padrão de código C++ unificado dá à equipe três vantagens principais:

\n
• Velocidade de onboarding. O novo membro não precisa adivinhar como se escreve aqui — ele simplesmente olha qualquer arquivo e vê o padrão.
\n
• Mínimo de conflitos em code review. Em vez de "reescreva a indentação", vocês discutem arquitetura e lógica.
\n
• Automação. Formatadores e linters assumem a rotina, liberando a mente para a criatividade.
\n

A boa notícia: você não precisa reinventar a roda. Existem best practices C++ comprovadas que se adaptam a qualquer projeto.

Principais convenções C++: da nomenclatura à formatação

Vamos passar pelos blocos principais que vale a pena definir em um guia de code style. Para cada item, darei um exemplo de "ruim" e "bom".

1. Nomenclatura: snake_case vs CamelCase vs PascalCase

Em C++, historicamente, surgiu uma abordagem híbrida. A biblioteca padrão usa snake_case, muitas empresas (Google, Microsoft) também o preferem para variáveis e funções. Para classes e structs, geralmente se usa PascalCase.

Exemplo de nomenclatura ruim:

class datamanager {\n    int numberOfElements;\n    void ProcessData(int* ptr) { ... }\n};

Problemas: classe em snake_case, método em CamelCase, sem contexto. Melhor assim:

class DataManager {\n    int number_of_elements_;\n    void ProcessData(int* data_ptr) { ... }\n};

O que foi corrigido aqui:

\n
• Classe — PascalCase.
\n
• Campos — snake_case com sufixo de sublinhado para membros privados (estilo Google).
\n
• Método — PascalCase (ou snake_case, se adotado pela equipe).
\n
• Parâmetro — snake_case com sufixo _ptr, para ficar claro imediatamente que é um ponteiro.
\n

Dica: escolha um estilo para todo o projeto. Misturar getValue() e get_value() no mesmo arquivo é o caminho certo para a confusão.

2. Formatação: espaços, chaves e comprimento de linhas

A fonte mais comum de discussões é onde colocar a chave de abertura: na mesma linha ou na próxima? Em C++, é comum colocá-la na mesma linha (estilo K&R), mas há variações.

Exemplo de estilo consistente:

void CalculateSum(const std::vector<int>& values) {\n    int sum = 0;\n    for (size_t i = 0; i < values.size(); ++i) {\n        sum += values[i];\n    }\n    return sum;\n}

Aqui tudo é uniforme: chave após if, fo