;
/** Permite criar uma função de agregação pelo seu nome.
*/
class AggregateFunctionFactory
{
public:
AggregateFunctionFactory();
AggregateFunctionPtr get(const String & name, const DataTypes & argument_types) const;
```
**15.** `namespace`.
Não é necessário usar um `namespace` separado para o código da aplicação.
Bibliotecas pequenas também não precisam disso.
Para bibliotecas de médio a grande porte, coloque tudo em um `namespace`.
No arquivo `.h` da biblioteca, você pode usar `namespace detail` para ocultar detalhes de implementação desnecessários para o código da aplicação.
Em um arquivo `.cpp`, você pode usar `static` ou um `namespace` anônimo para ocultar símbolos.
Além disso, um `namespace` pode ser usado com um `enum` para evitar que os nomes correspondentes vazem para um `namespace` externo (mas é melhor usar `enum class`).
**16.** Inicialização adiada.
Se a inicialização exigir argumentos, normalmente você não deve escrever um construtor padrão.
Se mais tarde for preciso adiar a inicialização, você pode adicionar um construtor padrão que criará um objeto inválido. Ou, para um número pequeno de objetos, usar `shared_ptr/unique_ptr`.
```cpp theme={null}
Loader(DB::Connection * connection_, const std::string & query, size_t max_block_size_);
/// Para inicialização adiada
Loader() {}
```
**17.** Funções virtuais.
Se a classe não se destina ao uso polimórfico, não é necessário tornar as funções virtuais. Isso também se aplica ao destrutor.
**18.** Codificações.
Use UTF-8 em todos os lugares. Use `std::string` e `char *`. Não use `std::wstring` nem `wchar_t`.
**19.** Logging.
Veja os exemplos ao longo do código.
Antes de fazer commit, remova todo logging sem sentido e de depuração, bem como quaisquer outros tipos de saída de depuração.
O logging em loops deve ser evitado, mesmo no nível Trace.
Os logs devem ser legíveis em qualquer nível de log.
Em geral, o logging deve ser usado apenas no código da aplicação.
As mensagens de log devem ser escritas em inglês.
De preferência, o log deve ser compreensível para o administrador do sistema.
Não use palavrões no log.
Use codificação UTF-8 no log. Em casos raros, você pode usar caracteres não ASCII no log.
**20.** Entrada e saída.
Não use `iostreams` em loops internos críticos para o desempenho da aplicação (e nunca use `stringstream`).
Use a biblioteca `DB/IO` em vez disso.
**21.** Data e hora.
Veja a biblioteca `DateLUT`.
**22.** include.
Sempre use `#pragma once` em vez de guardas de inclusão.
**23.** using.
Não use `using namespace`. Você pode usar `using` para algo específico. Mas mantenha isso local dentro de uma classe ou função.
**24.** Não use `trailing return type` para funções, a menos que seja necessário.
```cpp theme={null}
auto f() -> void
```
**25.** Declaração e inicialização de variáveis.
```cpp theme={null}
//forma correta
std::string s = "Hello";
std::string s{"Hello"};
//forma incorreta
auto s = std::string{"Hello"};
```
**26.** Para funções virtuais, escreva `virtual` na classe base, mas use `override` em vez de `virtual` nas classes derivadas.
## Funcionalidades não utilizadas do C++
**1.** Herança virtual não é usada.
**2.** Construções que ganharam açúcar sintático no C++ moderno, por exemplo.
```cpp theme={null}
// Forma tradicional sem açúcar sintático
template ::value, void>> // SFINAE via std::enable_if, uso de ::value
std::pair func(const E & e) // tipo de retorno especificado explicitamente
{
if (elements.count(e)) // teste de pertencimento .count()
{
// ...
}
elements.erase(
std::remove_if(
elements.begin(), elements.end(),
[&](const auto x){
return x == 1;
}),
elements.end()); // idioma remove-erase
return std::make_pair(1, 2); // cria par via make_pair()
}
// Com açúcar sintático (C++14/17/20)
template
requires std::same_v // SFINAE via conceito C++20, uso de alias de template C++14
auto func(const E & e) // tipo de retorno auto (C++14)
{
if (elements.contains(e)) // teste de pertencimento .contains do C++20
{
// ...
}
elements.erase_if(
elements,
[&](const auto x){
return x == 1;
}); // std::erase_if do C++20
return {1, 2}; // ou: return std::pair(1, 2); // cria par via lista de inicialização ou inicialização por valor (C++17)
}
```
## Plataforma
**1.** Escrevemos código para uma plataforma específica.
Mas, mantidas as demais condições, dá-se preferência a código multiplataforma ou portável.
**2.** Linguagem: C++20 (veja a lista de [recursos disponíveis do C++20](https://en.cppreference.com/w/cpp/compiler_support#C.2B.2B20_features)).
**3.** Compilador: `clang`. No momento em que este texto foi escrito (março de 2025), o código é compilado com clang versão >= 19.
A biblioteca padrão utilizada é a `libc++`.
**4.** SO: Ubuntu Linux, não anterior ao Precise.
**5.** O código é escrito para a arquitetura de CPU x86\_64.
O conjunto de instruções da CPU é o conjunto mínimo compatível entre nossos servidores. Atualmente, é SSE 4.2.
**6.** Use as flags de compilação `-Wall -Wextra -Werror -Weverything`, com algumas exceções.
**7.** Use vinculação estática com todas as bibliotecas, exceto aquelas que são difíceis de vincular estaticamente (veja a saída do comando `ldd`).
**8.** O código é desenvolvido e depurado com configurações de release.
## Ferramentas
**1.** O KDevelop é uma boa IDE.
**2.** Para depuração, use `gdb`, `valgrind` (`memcheck`), `strace`, `-fsanitize=...` ou `tcmalloc_minimal_debug`.
**3.** Para análise de desempenho, use `Linux Perf`, `valgrind` (`callgrind`) ou `strace -cf`.
**4.** O código-fonte está no Git.
**5.** A compilação usa `CMake`.
**6.** Os programas são distribuídos em pacotes `deb`.
**7.** Commits na master não devem quebrar a compilação.
Embora apenas revisões selecionadas sejam consideradas funcionais.
**8.** Faça commits com a maior frequência possível, mesmo que o código esteja apenas parcialmente pronto.
Use branches para isso.
Se o seu código na branch `master` ainda não puder ser compilado, exclua-o da compilação antes do `push`. Você precisará finalizá-lo ou removê-lo em poucos dias.
**9.** Para alterações não triviais, use branches e publique-as no servidor.
**10.** Código não utilizado é removido do repositório.
## Bibliotecas
**1.** A biblioteca padrão do C++20 é usada (extensões experimentais são permitidas), assim como os frameworks `boost` e `Poco`.
**2.** Não é permitido usar bibliotecas de pacotes do sistema operacional. Também não é permitido usar bibliotecas pré-instaladas. Todas as bibliotecas devem ser incluídas como código-fonte no diretório `contrib` e compiladas com o ClickHouse. Consulte [Diretrizes para adicionar novas bibliotecas de terceiros](/pt-BR/resources/develop-contribute/contribute/contrib#adding-and-maintaining-third-party-libraries) para mais detalhes.
**3.** A preferência é sempre por bibliotecas que já estão em uso.
## Recomendações gerais
**1.** Escreva o mínimo de código possível.
**2.** Tente a solução mais simples.
**3.** Não escreva código até saber como ele vai funcionar e como o laço interno vai operar.
**4.** Nos casos mais simples, use `using` em vez de classes ou structs.
**5.** Se possível, não implemente construtores de cópia, operadores de atribuição, destrutores (exceto um virtual, se a classe contiver pelo menos uma função virtual), construtores de movimento nem operadores de atribuição por movimento. Em outras palavras, as funções geradas pelo compilador devem funcionar corretamente. Você pode usar `default`.
**6.** A simplificação do código é incentivada. Reduza o tamanho do código sempre que possível.
## Recomendações adicionais
**1.** Especificar explicitamente `std::` para tipos de `stddef.h`
não é recomendável. Em outras palavras, recomendamos escrever `size_t` em vez de `std::size_t`, porque é mais curto.
É aceitável adicionar `std::`.
**2.** Especificar explicitamente `std::` para funções da biblioteca padrão de C
não é recomendável. Em outras palavras, escreva `memcpy` em vez de `std::memcpy`.
O motivo é que existem funções não padrão semelhantes, como `memmem`. Nós as usamos ocasionalmente. Essas funções não existem no `namespace std`.
Se você escrever `std::memcpy` em vez de `memcpy` em todos os lugares, `memmem` sem `std::` vai parecer estranho.
Ainda assim, você pode usar `std::` se preferir.
**3.** Usar funções de C quando as mesmas estiverem disponíveis na biblioteca padrão de C++.
Isso é aceitável se for mais eficiente.
Por exemplo, use `memcpy` em vez de `std::copy` para copiar grandes blocos de memória.
**4.** Argumentos de função em várias linhas.
Qualquer um dos estilos de quebra de linha a seguir é permitido:
```cpp theme={null}
function(
T1 x1,
T2 x2)
```
```cpp theme={null}
function(
size_t left, size_t right,
const & RangesInDataParts ranges,
size_t limit)
```
```cpp theme={null}
function(size_t left, size_t right,
const & RangesInDataParts ranges,
size_t limit)
```
```cpp theme={null}
function(size_t left, size_t right,
const & RangesInDataParts ranges,
size_t limit)
```
```cpp theme={null}
function(
size_t left,
size_t right,
const & RangesInDataParts ranges,
size_t limit)
```