title_wip

elements.erase(
        std::remove_if(
            elements.begin(), elements.end(),
            [&](const auto x){
                return x == 1;
            }),
        elements.end()); // remove-erase idiom

    return std::make_pair(1, 2); // create pair via make_pair()
}

// With syntactic sugar (C++14/17/20)
template <typename G>
requires std::same_v<G, F> // SFINAE via C++20 concept, usage of C++14 template alias
auto func(const E<G> & e) // auto return type (C++14)
{
    if (elements.contains(e)) // C++20 .contains membership test
    {
        // ...
    }

    elements.erase_if(
        elements,
        [&](const auto x){
            return x == 1;
        }); // C++20 std::erase_if

    return {1, 2}; // or: return std::pair(1, 2); // create pair via initialization list or value initialization (C++17)
}
```

## Platform[​](#platform "Direct link to Platform")

**1.** We write code for a specific platform.

But other things being equal, cross-platform or portable code is preferred.

**2.** Language: C++20 (see the list of available [C++20 features](https://en.cppreference.com/w/cpp/compiler_support#C.2B.2B20_features)).

**3.** Compiler: `clang`. At the time of writing (March 2025), the code is compiled using clang version >= 19.

The standard library is used (`libc++`).

**4.** OS: Linux Ubuntu, not older than Precise.

**5.** Code is written for x86\_64 CPU architecture.

The CPU instruction set is the minimum supported set among our servers. Currently, it is SSE 4.2.

**6.** Use `-Wall -Wextra -Werror -Weverything` compilation flags with a few exception.

**7.** Use static linking with all libraries except those that are difficult to connect to statically (see the output of the `ldd` command).

**8.** Code is developed and debugged with release settings.

## Tools[​](#tools "Direct link to Tools")

**1.** KDevelop is a good IDE.

**2.** For debugging, use `gdb`, `valgrind` (`memcheck`), `strace`, `-fsanitize=...`, or `tcmalloc_minimal_debug`.

**3.** For profiling, use `Linux Perf`, `valgrind` (`callgrind`), or `strace -cf`.

**4.** Sources are in Git.

**5.** Assembly uses `CMake`.

**6.** Programs are released using `deb` packages.

**7.** Commits to master must not break the build.

Though only selected revisions are considered workable.

**8.** Make commits as often as possible, even if the code is only partially ready.

Use branches for this purpose.

If your code in the `master` branch is not buildable yet, exclude it from the build before the `push`. You'll need to finish it or remove it within a few days.

**9.** For non-trivial changes, use branches and publish them on the server.

**10.** Unused code is removed from the repository.

## Libraries[​](#libraries "Direct link to Libraries")

**1.** The C++20 standard library is used (experimental extensions are allowed), as well as `boost` and `Poco` frameworks.

**2.** It is not allowed to use libraries from OS packages. It is also not allowed to use pre-installed libraries. All libraries should be placed in form of source code in `contrib` directory and built with ClickHouse. See [Guidelines for adding new third-party libraries](/docs/development/contrib#adding-and-maintaining-third-party-libraries) for details.

**3.** Preference is always given to libraries that are already in use.

## General recommendations[​](#general-recommendations-1 "Direct link to General recommendations")

**1.** Write as little code as possible.

**2.** Try the simplest solution.

**3.** Don't write code until you know how it's going to work and how the inner loop will function.

**4.** In the simplest cases, use `using` instead of classes or structs.

**5.** If possible, do not write copy constructors, assignment operators, destructors (other than a virtual one, if the class contains at least one virtual function), move constructors or move assignment operators. In other words, the compiler-generated functions must work correctly. You can use `default`.

**6.** Code simplification is encouraged. Reduce the size of your code where possible.

## Additional recommendations[​](#additional-recommendations "Direct link to Additional recommendations")

**1.** Explicitly specifying `std::` for types from `stddef.h`

is not recommended. In other words, we recommend writing `size_t` instead `std::size_t`, because it's shorter.

It is acceptable to add `std::`.

**2.** Explicitly specifying `std::` for functions from the standard C library

is not recommended. In other words, write `memcpy` instead of `std::memcpy`.

The reason is that there are similar non-standard functions, such as `memmem`. We do use these functions on occasion. These functions do not exist in `namespace std`.

If you write `std::memcpy` instead of `memcpy` everywhere, then `memmem` without `std::` will look strange.

Nevertheless, you can still use `std::` if you prefer it.

**3.** Using functions from C when the same ones are available in the standard C++ library.

This is acceptable if it is more efficient.

For example, use `memcpy` instead of `std::copy` for copying large chunks of memory.

**4.** Multiline function arguments.

Any of the following wrapping styles are allowed:

```
function(
  T1 x1,
  T2 x2)
```

```
function(
  size_t left, size_t right,
  const & RangesInDataParts ranges,
  size_t limit)
```

```
function(size_t left, size_t right,
  const & RangesInDataParts ranges,
  size_t limit)
```

```
function(size_t left, size_t right,
      const & RangesInDataParts ranges,
      size_t limit)
```

```
function(
      size_t left,
      size_t right,
      const & RangesInDataParts ranges,
      size_t limit)
```

- [General recommendations](#general-recommendations)- [Formatting](#formatting)- [Comments](#comments)- [Names](#names)- [How to write code](#how-to-write-code)- [Unused features of C++](#unused-features-of-c)- [Platform](#platform)- [Tools](#tools)- [Libraries](#libraries)- [General recommendations](#general-recommendations-1)- [Additional recommendations](#additional-recommendations)

Was this page helpful?