CodeStyle и всё с ним связанное

# Стиль кодирования на C++

{{toc}}

Данный стиль кодирования основан на 

Google C++ Style Guide(attachment:cppguide.pdf). В отличие от Google 

мы не испытываем страха перед исключениями, помимо этого, у нас свои соглашения 

об именовании переменных, констант и функций. На ~80%, текст соответствует 

переводу с хабра.

## Введение

Цель руководства — управление сложностью кода, путем описания в деталях как 

стоит (или не стоит) писать код на C++. Правила этого руководства упростят 

управление кодом и увеличат продуктивность программистов.

*Стиль кодирования (codestyle)* — соглашения, которым следует C++ код. Стиль — 

это больше, чем форматирование файла с кодом.

> *Примечание:* это руководство не является учебником по C++: предполагается, 

> что вы знакомы с языком.

### Цели Руководства по стилю

Зачем нужен этот документ?

Есть несколько основных целей этого документа, лежащих в основе отдельных 

правил. Используя эти цели можно избежать длинных дискуссий: почему правила 

такие и зачем им следовать. Если вы понимаете цели каждого правила, то вам легче

с ними согласиться или отвергнуть, оценить альтернативы при изменении правил 

под себя.

Цели руководства следующие:

 * Правила должны стоить изменений

   * Преимущества от использования единого стиля должны перевешивать 

   недовольство инженеров по запоминанию и использованию правил.

   * Преимущество оценивается по сравнению с кодовой базой без применения 

   правил, поэтому если ваши люди всё равно не будут применять правила, то 

   выгода будет очень небольшой.

   * Этот принцип объясняет почему некоторые правила отсутствуют: например, 

   `goto` нарушает многие принципы, однако он практически не используется, 

   поэтому Руководство это не описывает.

 * Удобство для читателя, а не для писателя

   * Кодовая база (и большинство отдельных компонентов из неё) будет 

   использоваться продолжительное время. Поэтому, на чтение этого кода будет 

   тратиться существенно больше времени, чем на написание.

   * Код должен легко читаться, поддерживаться и отлаживаться. Как следствие,

   принцип *оставь подсказку для читателя, когда код работает странно*. Если код

   работает неочевидно, следует использовать такие конструкции, которые явным 

   образом укажут, как именно он работает. Например, использование 

   `std::unique_ptr` **явно** показывает передачу владения.

   * Кадры приходят и уходят, а хорошо читаемый код позволяет новым специалистам

   быстрее вникать в работу

 * Согласование с существующим кодом

   * Использование единого стиля на кодовой базе позволяет переключиться на 

   другие, более важные, вопросы.

   * Согласованность позволяет использовать автоматическое форматирование кода. 

     Если код всегда написан похожим образом, то и автоформатирование будет 

     давать похожий результат.

   * Во многих случаях *согласованность* вырождается до: *выбери из нескольких*

   *вариантов самый подходящий*, а некоторая гибкость в использовании правил 

   позволяет людям меньше спорить.

 * По возможности, код должен быть согласован с кодом максимально широкого 

 C++-сообщества

   * Согласованность кода с кодом других организаций и сообществ весьма полезна. 

   Если возможности стандартного C++ или принятые идиомы языка облегчают 

   написание программ, это повод их использовать. Однако иногда особенности 

   стандарта и идиомы имеют изъяны или неприменимы для внедрения в текущую 

   кодовую базу. В этих случаях (как описано ниже) имеет смысл ограничить или 

   запретить использование некоторых стандартных возможностей. В некоторых 

   случаях создаётся свое решение, которое работает поверх стандартных 

   библиотек, иногда это слишком затратно.

 * Минимизация неочевидных или опасных конструкций

   * Некоторые особенности языка С++ более неочевидны, чем может показаться на 

   первый взгляд. Стоит избегать конструкций, если их использование несет больше

   рисков, чем пользы.

 * Минимизация конструкций, сложных или трудно поддерживаемых для 

 среднестатистического программиста на C++

   * В C++ есть возможности, которые в целом не приветствуются по причине 

   усложнения кода. В часто используемом коде применение хитрых конструкций 

   оправданно, поскольку однократные затраты на понимание сложных вещей будут 

   оправданы преимуществами от более сложной реализации. 

   * Код переходит из рук в руки, а специалисты меняются, поэтому ситуация, 

   когда все в команде понимают какой-то сложный фрагмент кода может поменяться 

   со временем.

 * Масштаб кода должен учитываться

   * С кодовой базой более 100 миллионов строк и тысячами инженеров, ошибки и 

   упрощения могут дорого обойтись. Например, важно избегать замусоривания 

   глобального пространства имён: коллизии имён очень сложно избежать в большой 

   кодовой базе если всё объявляется в глобальном пространстве имён.

 * Использование оптимизации по мере необходимости

   * Оптимизация производительности иногда важнее, чем следование правилам в 

   кодировании.

Намерение этого документа — обеспечить максимально понятное руководство при 

разумных ограничениях. Как всегда, здравый смысл всегда превалирует над 

документом. Относитесь со скепсисом к хитрым или необычным конструкциям: 

отсутствие ограничения не всегда есть разрешение. И, если не можешь решить сам, 

спроси начальника.

### Версия C++

Сейчас код должен соответствовать C++17, т.е. возможности C++2x нежелательны. 

В дальнейшем, руководство будет корректироваться на более новые версии C++.

Не используйте нестандартные расширения. Учитывайте совместимость с другим 

окружением, если собираетесь использовать C++14 и C++17 в своём проекте.

## Заголовочные файлы

В общем случае, каждый `.cpp`-файл должен иметь парный `.hpp` файл. Есть 

исключения, например, модульные тесты или небольшие файлы, содержащие только 

функцию `main()`.

Корректное использование заголовочных файлов может иметь огромное влияние на 

читаемость, размер и производительность кода.

Нижеописанные правила помогут вам избежать различных трудностей при 

использовании заголовочных файлов.

### Самодостаточные заголовочные файлы

Заголовочные файлы должны быть *самодостаточными* и иметь расширение `.hpp`. 

Незаголовочные файлы, предназначенные для включения в код, должны быть с 

расширением `.inc` и использоваться осторожно.

*Самодостаточность (self-containment)* заголовочного файла означает, что 

пользователи или утилиты для рефакторинга должны включать заголовочный файл без

каких-либо дополнительных условий. Например, файл `a.hpp` не должен требовать, 

чтобы в файл с исходным кодом также был включен файл `b.cpp`.

Заголовочный файл должен иметь защиту от повторного включения и включать все 

необходимые файлы.

При объявлении в заголовочном файле inline-функций или шаблонов, которые будут 

использоваться пользователем данного файла, определения этих функций или 

шаблонов должны присутствовать либо в самом заголовочном файле, либо в файле, 

включенном непосредственно в него. Не следует переносить определения в отдельный

заголовочный файл (`inl.hpp`). Так раньше было принято, но теперь это 

нежелательно. Если все специализации шаблона явно определены в `.cpp`-файле или 

если шаблон используется только в нем, определение шаблона можно оставить в этом 

файле.

В редких случаях включаемые файлы не являются самодостаточными и включаются в 

середину другого файла. Такие файлы могут не иметь защиты от повторного 

включения и не включать заголовочные файлы с зависимостями. Такие файлы должны 

иметь расширение `.inc` и использоваться редко. Использование самодостаточных 

заголовочных файлов остается предпочтительным.

### Защита от повторного включения

Предпочтительнее использовать директиву `#pragma once`, чем пару 

`#ifndef/#define/#endif`. Это связано с тем, что последний нарушает принцип DRY, 

поскольку название заголовочного файла фигурирует в нескольких местах и при 

рефакторинге приходится менять и сами макросы. 

В некоторых случаях, например, если возможно включение одного и того же файла 

из разных мест, `#pragma once` может не работать. В подобных ситуациях или 

где-то еще, можно использовать макросы. В этом случае формат макроопределения 

иметь следующий вид:`<PROJECT>_<PATH>_<FILE>_H_`. Например, файл 

`foo/src/bar/baz.h` в проекте foo может иметь следующую блокировку:

```c++

#ifndef FOO_BAR_BAZ_H_

#define FOO_BAR_BAZ_H_

...

#endif // FOO_BAR_BAZ_H_

```

### Включайте только то, что используете

Если файл ссылается на сущность, определенную в другом месте, этот файл должен 

напрямую включать заголовочный файл, который предоставляет объявление или 

определение данной сущности. Заголовочный файл не должен включаться по 

какой-либо другой причине.

Не стоит рассчитывать на то, что данный заголовочный файл подключается 

опосредованно, через какой-то другой. В процессе работы над тем файлом, 

ненужное `#include`-выражение может быть убрано. Таким образом, файл `foo.cpp` 

должен напрямую включать `bar.hpp`, при использовании сущностей, объявленных 

там, даже если файл `foo.hpp` также его включает. Это один из аспектов 

самодостаточности.

### Предварительное объявление

Избегайте использования предварительных объявлений в `.cpp`-файлах, если это 

возможно. Вместо этого включайте нужные файлы.

*Предварительное объявление (forward declaration)* - это объявление сущности без 

определения, например:

```c++

// In a C++ source file:

class B;

void FuncInB();

extern int variable_in_b;

ABSL_DECLARE_FLAG(flag_in_b);

```

 * Предварительное объявление может уменьшить время компиляции. Использование 

 `#include` требует от компилятора сразу открывать и обрабатывать больше файлов.

 * Предварительное объявление позволит избежать ненужной перекомпиляции. 

 Применение `#include` может привести к частой перекомпиляции из-за различных 

 изменений в заголовочных файлах.

---

 * Предварительное объявление может скрывать зависимости от перекомпиляции при 

 изменении заголовочных файлов.

 * Предварительное объявление хуже обрабатывается специальными утилитами.

 * При изменении API, предварительное объявление может стать некорректным. 

 Как результат, предварительное объявление функции или шаблонов может 

 блокировать изменение API: замена типов параметров на похожий, добавление 

 параметров по умолчанию в шаблон, перенос в новое пространство имён.

 * Предварительное объявление символов из std:: может вызвать неопределённое 

 поведение.

 * Иногда тяжело понять, что лучше подходит: предварительное объявление или 

 обычный `#include`. Однако, замена `#include` на предварительное объявление 

 может (без предупреждений) поменять смысл кода:

```c++

// b.hpp:

struct B {};

struct D : B {};

```

``` c++

// good_user.cpp:

#include "b.hpp"

void f(B*);

void f(void*);

void test(D* x) { f(x); } // calls f(B*)

```

Если в коде заменить `#include` на предварительное объявление для структур 

`B` и `D`, то `test()` будет вызывать `f(void*)`.

* Предварительное объявление множества сущностей может быть чересчур объёмным, 

и может быть проще подключить заголовочный файл.

* Структура кода, допускающая предварительное объявление 

(и, далее, использование указателей в качестве членов класса) может сделать код 

запутанным и медленным.

---

_Вывод:_

При всем этом, использование предварительного объявления классов в заголовочном 

файле практически лишено данных минусов. Предварительное объявление шаблонных 

классов выглядит громоздким и его следует избегать. В `.cpp`-файлах следует

избегать предварительных определений.

### Inline-функции

Inline-функции (встраиваемые функции) - это функции, тело которой 

подставляется непосредственно в код при каждом вызове.

Определяйте функции как встраиваемые только когда они маленькие, например не 

более 10 строк.

Встраивание функций может генерировать более эффективный код, особенно когда 

функции очень маленькие. Такие функции удобно использовать для get/set-функции 

или коротких, но критичных для производительности функций.

Чрезмерное использование inline-функций может существенно замедлить программу. 

В зависимости от размера, их использование может как увеличить, так и уменьшить 

размер кода. На современных процессорах более компактный код выполняется быстрее

благодаря лучшему использованию кэша инструкций.

_Вывод:_

*Хорошее правило*: не объявлять функции встраиваемыми, если они длиннее 10 

строк. Осторожно с деструкторами! Деструктор неявно вызывает деструкторы 

родительских классов.

*Еще одно правило*: нет смысла делать функции встраиваемыми, если в них есть 

`switch` или цикл.

Важно понимать, что не всегда директива `inline` делает функцию встраиваемой, 

это зависит от компилятора. Например, виртуальные методы и рекурсивные функции 

небольшой размер, например get/set-функции.

### Названия и порядок включения заголовочных файлов

Включение заголовочных файлов должно производиться в следующем порядке: 

Связанный заголовочный файл, Системные заголовочные файлы на языке C, 

Файлы стандартной библиотеки, Другие библиотеки, Заголовочные файлы текущего 

проекта.

Все заголовочные файлы проекта должны указываться относительно директории 

исходных файлов проекта без использования таких UNIX псевдонимов как . 

(текущая директория) или .. (родительская директория). Например, 

`awesome-project/src/base/logging.hpp` должен включаться так:

``` c++

#include "base/logging.hpp"

```

Другой пример: если основная функция файлов `dir/foo.cpp` и `dir/foo_test.cpp` 

это реализация и тестирование кода, объявленного в `dir2/foo2.hpp`, 

то записывайте заголовочные файлы в следующем порядке:

1. `dir2/foo2.h`.

2. Пустая строка.

3. Системные заголовочные файлы C (точнее: файлы с включением угловыми скобками 

с расширением `.h`), например `<unistd.h>`, `<stdlib.h>`.

4. Пустая строка.

5. Заголовочные файлы стандартной библиотеки C++ (без расширения в файлах), 

например `<algorithm>`, `<cstddef>`.

6. Пустая строка.

7. Заголовочные `.h/.hpp` файлы других библиотек.

8. Пустая строка.

9. Файлы `.hpp` вашего проекта.

Отделяйте каждую непустую группу файлов пустой строкой.

Такой порядок файлов позволяет выявить ошибки, когда в парном заголовочном файле 

(`dir2/foo2.hpp`) пропущены необходимые заголовочные файлы (системные и др.) и 

сборка соответствующих файлов `dir/foo.cpp` или `dir/foo_test.cc` 

завершится ошибкой. Как результат, ошибка сразу же появится у разработчика, 

работающего с этими файлами (а не у другой команды, которая только использует 

внешнюю библиотеку).

Учтите, что заголовочные файлы C, такие как `stddef.h` обычно взаимозаменяемы

 соответствующими файлами C++ (`cstddef`). Можно использовать любой вариант, 

но лучше следовать стилю существующего кода.

Внутри каждой секции заголовочные файлы следует перечислять в 

алфавитном порядке. Учтите, что ранее написанный код может не следовать этому 

правилу. По возможности (например, при исправлениях в файле), исправляйте 

порядок файлов на правильный, если это удобно.

Например, список заголовочных файлов в 

`awesome-project/src/foo/internal/fooserver.cpp` может выглядеть так:

``` c++

#include "foo/server/fooserver.hpp"

#include <sys/types.h>

#include <unistd.h>

#include <string>

#include <vector>

#include "base/basictypes.hpp"

#include "base/commandlineflags.hpp"

#include "foo/server/bar.hpp"

```

#### Исключения

Бывают случаи, когда требуется включение заголовочных файлов в зависимости от 

условий препроцессора (например, в зависимости от используемой ОС). Включение системно-зависимых файлов стоит

держать локализованным фрагментом после других заголовочных файлов. Например:

``` c++

#include "foo/public/fooserver.h"

#include "base/port.h"

// For LANG_CXX11.

#ifdef LANG_CXX11

#include <initializer_list>

#endif // LANG_CXX11

```

## Область видимости

### Пространства имен

Код, за некоторым исключением должен быть размещен в пространстве имен. 

Имена пространств имен должны быть уникальными и основываться на названии и, 

возможно, пути проекта. Не используйте *using-директивы* 

(`using namespace std`). Не используйте inline пространства имен. Для 

безымянных пространств имен см. 

[внутреннее связывание](#Внутреннее-связывание-Internal-Linkage).

*Пространства имен (namespaces)* разбивают глобальную область видимости на

несколько, отдельных и именованных. Это помогает предотвращать коллизии имен в 

глобальной области видимости. 

Пространства имен позволяют избегать конфликтов названий, при этом, большая 

часть кода использует короткие названия.

Например, представим себе, что два различных проекта имеют класс `Foo` в 

глобальной области видимости. Эти сущности могут столкнуться как во время 

компиляции, так и во время исполнения. Если код каждый проект будет помещен в 

свое пространство имен, то теперь `project1::Foo` и `project2::Foo` - это две 

отдельных сущности, и теперь коллизия не возникнет, при этом внутри проектов 

обращение к соответствующему классу `Foo` будет осуществляться без каких-либо 

префиксов.

Inline-пространства имен автоматически подставляют названия в окружающую область 

видимости. Например:

```c++

namespace outer {

inline namespace inner {

    void foo();

} // namespace inner

} // namespace outer

```

Выражения `outer::inner::foo()` и `outer::foo()` - взаимозаменяемы. 

Inline-пространства имён в основном используются для совместимости ABI между 

версиями.

Пространства имен могут запутать, поскольку они усложняют понимание того, какое

определение к какому названию относится.

Inline-пространства имен запутывают еще сильнее, поскольку название не 

ограничены своим пространством имен. Это просто полезная часть политики 

управления версиями.

В ряде случаев требуется использование полных имён, что может добавить в код 

беспорядка.

Пространства имен следует использовать следующим образом:

 * Следуйте [правилам](#Именование-пространства-имён-namespace) именования 

 пространств имен.

 * Завершайте пространства имен комментариями, как в примере ниже

 * Заключайте в пространство имён целиком файл с исходным кодом после 

 `#include`-ов, макросов, объявлений/определений `gflag`-ов и предварительных 

 объявлений классов из других пространств имён.

``` c++

// В .hpp файле

namespace mynamespace {

// Все объявления внутри блока пространства имён.

// Обратите внимание на отсутствие отступа.

class MyClass {

public:

...

void Foo();

};

} // namespace mynamespace

```

``` c++

// В .cpp файле

namespace mynamespace {

// Определение функций внутри блока пространства имён.

void MyClass::Foo() {

...

}

} // namespace mynamespace

```

 * Не объявляйте ничего в пространстве имен `std`. В том числе и предварительные

 объявления.

 * Не используйте директиву `using namespace ...;` - это загрязняет глобальное 

 пространство имен.

 * Не используйте using-объявление `using foo::Bar;` в заголовочных файлах.

 * Не используйте псевдонимы пространств имен в заголовочных файлах за 

 исключением явно внутренних пространств имен.

``` с++

// Укороченная запись для доступа к часто 

// используемым именам в .cpp файлах - Нормально

namespace baz = ::foo::bar::baz;

```

``` c++

// Укороченная запись для доступа к часто используемым именам (в .hpp файле).

namespace librarian {

namespace impl { // Внутреннее содержимое, не являющееся частью API.

namespace sidetable = ::pipeline_diagnostics::sidetable;

} // namespace impl

inline void my_inline_function() {

    // Пространство имён, локальное для функции (или метода).

    namespace baz = ::foo::bar::baz;

...

}

} // namespace librarian

```

 * Не используйте inline-пространства имен.

### Внутреннее связывание (Internal Linkage)

В том случае, если возможность ссылки на определения из `.cpp`-файла из других 

файлов должна быть запрещена, необходимо использовать внутреннее связывание. 

Для этого нужно либо объявить эти сущности как `static`, либо разместить их в 

безымянном пространстве имен (unnamed namespace). Не используйте внутреннее 

связывание в заголовочных файлах.

Форматирование безымянных пространств производится так же, как и именованных. 

В завершающем комментарии, название пространства имен должно быть оставлено 

пустым.

``` c++

namespace {

...

} // namespace

```

### Функции: глобальные, статические внутри и вне классов

Глобальные функции предпочтительно располагать в пространствах имен; используйте 

абсолютно глобальные функции как можно реже. Не используйте классы просто для 

того, чтобы сгруппировать статические члены. Статические методы класса должны 

быть сильно связаны с объектами данного класса или его статическими данными.

Глобальные и статические функции могут быть полезны в ряде случаев. Помещение

глобальных функций в пространство имен предотвращает загрязнение глобального 

пространства имен. 

Глобальные и статические функции могут стать понятнее при помещении в новый 

класс как функций-членов, особенно если они имеют доступ ко внешним ресурсам

или имеют явные зависимости.

Иногда полезно объявить функцию, не привязанную к объекту класса. Такие функции 

могут быть глобальными или статическими. Глобальная функция не должна иметь 

зависимостей от внешних переменных и практически всегда должна быть помещена

в пространство имен. Не создавайте класс для группировки таких функций.

Это ничем не отличается от обычного префикса и часто в этом нет смысла.

Если глобальная функция используется только в одном `.cpp`-файле, 

используйте [внутреннее связывание](#Внутреннее-связывание-Internal-Linkage).

### Локальные переменные

Располагайте локальные переменные функций в максимально узкой области видимости, 

инициализируйте эти переменные при объявлении. 

Язык C++ допускает объявление переменной в любом месте функции. Рекомендуется 

делать это в максимально локальной области видимости и максимально близко к 

месту первого использования. Так читателю будет проще найти объявление 

переменной и понять, каким значением она инициализирована. В частности 

инициализация более предпочтительна, чем объявление и присваивание. Например:

```c++

int i;

i = f(); // Плохо -- инициализация отделена от объявления.

int j = g(); // Хорошо -- объявление с инициализацией.

std::vector<int> v;

v.push_back(1); // Желательно инициализировать с помощью {}.

v.push_back(2);

std::vector<int> v = {1, 2}; // Хорошо -- v сразу инициализирован.

```

Переменные, необходимые для использования внутри конструкций `if`, `while`, 

`for`, следует объявлять внутри условий цикла. Тогда их область видимости будет

ограничена этими циклами:

```c++

while (const char* p = strchr(str, '/')) str = p + 1;

```

Существует тонкость: Если переменная - это объект, то его конструктор будет 

вызываться каждый раз при входе в область видимости, а деструктор - при выходе 

из нее. 

```c++

// Неэффективная реализация:

for (int i = 0; i < 1000000; ++i) {

    Foo f; // Конструктор и деструктор Foo вызовутся по 1000000 раз каждый.

    f.DoSomething(i);

}

```

Объявление такой переменной вне цикла может быть более эффективным:

```c++

Foo f; // Конструктор и деструктор Foo вызовутся по одному разу.

for (int i = 0; i < 1000000; ++i) {

    f.DoSomething(i);

}

```

### Статические и глобальные переменные

В статической области видимости (static storage duration) запрещены объекты, 

за исключением тривиально удаляемых (trivially destructible). Это значит, что 

деструктор такого объекта не должен делать ничего. Это же относится и к 

деструкторам базовых классов, поскольку они будут вызваны неявно. 

Более формально: тип не содержит пользовательского или виртуального деструктора,

а также все его члены и базовые типы являются тривиально-удаляемыми. Статические

переменные в функциях могут использовать динамическую инициализацию. 

Динамическая инициализация в статических переменных классов или глобальных 

переменных не приветствуется, но разрешена в некоторых случаях. Подробнее ниже.

_Хорошее правило:_ глобальная переменная удовлетворяет данным требованиям, 

если она может быть объявлена как `constexpr`.

У каждого объекта есть *время хранения (storage duration)*, которое соотносится 

с его временем жизни. Объекты со статическим временем хранения живут от точки 

инициализации и до конца работы программы. Такие объекты встречаются в качестве 

глобальных переменных, статических переменных классов и статических переменных 

функций. Все объекты со статическим временем хранения удаляются в фазе 

завершения программы (до обработки незавершённых потоков).

Инициализация может быть *динамической*, когда в конструкторе случается что-либо

нетривиальное, например выделение памяти, открытие файла, получение системных 

ресурсов. Другой вид инициализации - *статическая*. Одна инициализация не 

исключает другой: статическая инициализации выполняется в любом случае, 

затем, если необходимо, выполняется динамическая инициализация.

Глобальные и статические переменные очень полезны во многих применениях: 

именованные константы, внутренние дополнительные структуры данных, 

флаги командной строки, логирование, механизмы регистрации, организация 

внутренней инфраструктуры и т. д.

Глобальные и статические переменные, использующие динамическую инициализацию или

нетривиальные деструкторы могут легко привести к трудно обнаруживаемым багам. 

Порядок динамической инициализации и удаления между единицами трансляции 

не определен явно. Если один такой объект зависит от другого, то доступ к нему 

может осуществляться еще до того, как его время жизни началось или уже после 

того, как оно закончилось. Более того, когда приложение завершает потоки, 

они могут попытаться обратиться к уже удаленным или удаляемым объектам.

#### Ограничения по уничтожению

В случае с тривиальными деструкторами, их исполнение не зависит от порядка, 

поскольку, никакого "исполнения" деструкторов нет. В противном случае существует 

риск того, что доступ к объектам будет осуществляться после окончания их времени

жизни. По этой причине в статической области видимости разрешены только

тривиально-уничтожаемые объекты. Фундаментальные типы данных, такие как

указатели или `int` являются тривиально-уничтожаемыми, как и массивы

тривиально-уничтожаемых данных. Переменные, отмеченные как `constexpr` являются

тривиально-уничтожаемыми. 

```c++

const int kNum = 10; // Допустимо

struct X { int n; };

const X kX[] = {{1}, {2}, {3}}; // Допустимо

void foo() {

    static const char* const kMessages[] = {"hello", "world"}; // Допустимо

}

// Допустимо: constexpr всегда имеет тривиальный деструктор

constexpr std::array<int, 3> kArray = {{1, 2, 3}}

```

```c++

// Плохо: нетривиальный деструктор

const std::string kFoo = "foo";

// Плохо по тем же причинам (хотя kBar и является ссылкой, но 

// правило применяется и для временных объектов в расширенным временем жизни)

const std::string& kBar = StrCat("a", "b", "c");

void bar() {

    // Плохо: нетривиальный деструктор

    static std::map<int, int> kData = {{1, 0}, {2, 0}, {3, 0}};

}

```

_На заметку_ : ссылки не являются объектами, и на них не распространяются 

ограничения по уничтожению. Ограничения по инициализации все еще остаются. 

В частности, статическая ссылка в функции `static T& t = *new T` - разрешена.

#### Ограничения по инициализации

Инициализация - это более сложная тема, поскольку необходимо учитывать не только

выполнение конструктора класса, но и исполнения инициализации:

```c++

int n = 5;   // Отлично

int m = f(); // ? (Зависит от f)

Foo x;       // ? (Зависит от Foo::Foo)

Bar y = g(); // ? (Зависит от g и Bar::Bar)

```

Порядок инициализации для всех выражений, кроме первого, не определен.

Необходимо использовать концепцию, которая в стандарте C++ называется 

*константной* *инициализацией (constant initialization)*. Это значит, что 

выражение инициализации является *константным выражением (constant expression)*,

и если объект инициализируется вызовом конструктора, то конструктор должен быть 

объявлен как `constexpr`:

```c++

struct Foo { constexpr Foo(int) {} };

int n = 5;  // Отлично, 5 - константное выражение

Foo x(2);   // Отлично, 2 - константное выражение 

            // и вызывается constexpr конструктор

Foo a[] = { Foo(1), Foo(2), Foo(3) }; // Отлично

```

Константная инициализация всегда разрешена. Все нелокальные статические

переменные, конструкторы которых не помечены как `constexpr` должны 

восприниматься как динамически инициализируемые и тщательно проверяться.

Обратите внимание на следующие примеры:

```c++

// Объявления, используемые ниже

time_t time(time_t*);   // не constexpr !

int f();                // не constexpr !

struct Bar { Bar() {} };

// Проблемные инициализации

time_t m = time(nullptr);   // Выражение инициализации не константное

Foo y(f());                 // Те же проблемы

Bar b;                      // Конструктор Bar::Bar() не является constexpr

```

Динамическая инициализация переменных вне функций не рекомендуется. В общем 

случае это запрещено, однако, это можно делать если остальной код программы не 

зависит от порядка инициализации этой переменной. В этом случае изменение

порядка инициализации не может что-то изменить.

Например:

```c++

int p = getpid(); // Допустимо, пока другие статические переменные

                  // не используют p в своей инициализации

```

Динамическая инициализация статических локальных переменных функций допустима и

является широко распространённой практикой.

#### Рекомендуемые практики

 * Глобальные строки: Если требуется именованная глобальная или статическая 

 строковая переменная, используйте `constexpr string_view`, массив символов или 

 указатель, указывающий на строковый литерал.

 * Динамические контейнеры (`map`, `set` и т.д.): если требуется статическая

 коллекция с фиксированными данными (например, таблицы значений для поиска), то

 не используйте динамические контейнеры из стандартной библиотеки как тип для 

 статической переменной, т.к. у этих контейнеров нетривиальный деструктор. 

 Вместо этого попробуйте использовать массивы простых (тривиальных) типов, 

 например массив из массивов целых чисел (вместо `std::map<int, int>`) или, 

 например, массив структур с полями `int` и `const char*`. Учтите, что для

 небольших коллекций линейный поиск обычно вполне приемлем (и может быть очень 

 эффективным благодаря компактному размещению в памяти). Также можете 

 воспользоваться алгоритмами `absl/algorithm/container.h` для стандартных 

 операций. Также возможно создавать коллекцию данных уже отсортированной и 

 использовать алгоритм бинарного поиска. Если без динамического контейнера не 

 обойтись, то попробуйте использовать статическую переменную-указатель, 

 объявленную в функции (см. ниже).

 * Умные указатели (`unique_ptr`, `shared_ptr`): умные указатели освобождают 

 ресурсы в деструкторе и поэтому их нельзя использовать в качестве статических 

 или глобальных. Попробуйте применить другие практики/способы, описанные в 

 разделе. Например, одно из простых решений это использовать обычный указатель 

 на динамически выделенный объект и далее  никогда не удалять его 

 (см. последний вариант списка).

 * Статические переменные пользовательских типов: если необходима константа 

 типа, определённого вами, определяйте конструктор как `constexpr`, а 

 деструктор - тривиальным.

 * На крайний случай - создайте статический объект в функции динамически и 

 никогда его не удаляйте. (Например, 

 `static const auto& impl = new T(args...);`).

### thread_local-переменные

`thread_local`-переменные, которые объявлены вне функций должны 

инициализироваться константами времени компиляции(*true compile-time*). 

Используйте атрибут `ABSL_CONST_INIT` для того, чтобы в этом убедиться. 

Использование `thread_local` - это предпочтительный способ объявить данные 

внутрипотоковыми.

Начиная с C++11 переменные можно объявлять со спецификатором `thread_local`:

``` c++

thread_local Foo foo = ...;

```

Каждая такая переменная представляется собой коллекцию объектов. Каждый поток 

работает со своим экземпляром переменной. По поведению `thread_local`-переменные

во многом похожи на 

[статические переменные](#Статические-и-глобальные-переменные). Например, они 

могут быть объявлены в пространстве имён, внутри функций, как статические члены 

класса, но не как обычные члены класса.

Инициализация потоковых переменных очень напоминает статические переменные, 

за исключением что это делается для каждого потока. В том числе это означает, 

что объявлять `thread_local`-переменные внутри функции - безопасно, 

но остальные `thread_local`-переменные подвержены тем же проблемам, что и 

статические переменные.

Переменная `thread_local` не уничтожается до завершения потока, так что здесь 

нет проблем с порядком разрушения, как у статических переменных.

 * `thread_local`-переменные защищены от гонок, поскольку только один поток 

 имеет к ним доступ, что делает их использование полезным в многопоточных 

 приложениях;

 * `thread_local`-переменные - это единственный стандартный способ объявить 

 данные внутрипоточными.

 * Доступ к таким данным может спровоцировать исполнение непредсказуемого и 

 неконтролируемого количества кода.

 * По сути, `thread_local`-переменные являются глобальными со всеми вытекающими 

 недостатками.

 * Количество памяти, выделяемое для `thread_local`-переменных зависит от 

 количества запущенных потоков, что может быть чрезмерно большим.

 * `thread_local`-переменные могут менее эффективны, чем встроенные 

 (*compiler intrinsic*) функции компилятора.

Размещение `thread_local`-переменных внутри функции не влечет проблем с 

безопасностью, так что их можно использовать без ограничений. Можно использовать

такие переменные для организации глобального или статического доступа к данным, 

например:

```c++

Foo& MyThreadLocalFoo() {

    thread_local Foo result = ComplicatedInitialization();

    return result;

}

```

В области видимости класса или глобальной `thread_local`-переменных должны 

инициализироваться константами времени компиляции. Для того, чтобы это 

гарантировать используйте макрос `ABSL_CONST_INIT` или `constexpr`, но реже.

```c++

ABSL_CONST_INIT thread_local Foo foo = ...;

```

Используйте `thread_local` для объявления внутрипотоковых данных.

## Классы

Класс - это фундаментальная единица кода на C++. Обычно они используются очень 

широко. Данный раздел описывает все рекомендации, которым необходимо следовать 

при разработке классов.

### Выполнение задач в конструкторах

Избегайте вызовов виртуальных методов в конструкторах. Избегайте кода, который 

может завершиться ошибкой, если не будет способа о ней сообщить.

В конструкторе возможно выполнить любую инициализацию.

 * Нет необходимости заботиться о том, инициализирован объект класса или нет.

 * Объекты, которые целиком инициализируются в конструкторе могут быть 

константами. Также их проще использовать в контейнерах.

---

 * Если вызываются виртуальные функции, то не будут вызваны переопределения 

классов-наследников.

 * Нет простого способа сообщить об ошибке в конструкторе без аварийного

 завершения  программы.

или использования исключений.

 * Если инициализация провалилась, мы имеем объект в непонятном состоянии

 * Невозможно взять от конструктора адрес, поэтому возникают сложности с 

передачей конструктора в другой поток.

_Вывод:_

Конструкторы никогда не должны вызывать виртуальные функции. Используйте 

`init`-методы только в случае, если у объекта есть флаги состояния, разрешающие

вызывать те или иные публичные функции (т.к. сложно полноценно работать с 

частично сконструированным объектом).

### Неявное преобразование типов

Не используйте неявное преобразование типов. Используйте ключевое слово 

`explicit` для операторов преобразования типов или конструкторов с одним 

аргументом.

Неявное преобразование разрешает использование объектов одного типа там, 

где требуется использование объектов другого типа.

Программист может добавить свои механизмы для неявного преобразования типов 

путем добавления соответствующих членов в определение класса. Неявное 

преобразование в исходном типе может быть добавлено с помощью операторов 

преобразования типов, например `operator bool()`. Неявное преобразование в 

целевом типе реализуется при помощи конструктора с единственным аргументом 

исходного типа.

Ключевое слово `explicit` может быть применено к конструктору или оператору 

приведения типов, чтобы гарантировать, что неявное преобразование типов не 

будет работать. Это применимо не только к неявному преобразованию, но и к 

спискам инициализации. Например:

```c++

class Foo {

    explicit Foo(int x, double y);

    ...

};

void Func(Foo f);

Func({42, 3.14}); // Ошибка

```

Данный код не является примером неявного преобразования типов, но компилятор 

считает это таковым при использовании ключевого слова `explicit`.

 * Неявное преобразование может сделать тип удобнее или более выразительным 

 путем избавления от необходимости явно указывать целевой тип, когда это 

 очевидно.

 * Неявное преобразование может быть более простой альтернативой перегрузке 

 функций, например, если функция принимает параметр типа `string_view`, она 

 может принимать параметры типов `std::string` и `const char*`. 

 * Списки инициализации - это компактный и выразительный способ инициализации 

 объектов.

---

 * Использование списков инициализации могут скрыть ошибки несоответствия типов.

 * Неявное преобразование может сделать код более сложным для чтения, особенно

 когда также присутствуют и виртуальные функции.

 * Конструкторы с одним аргументом могут быть случайно использованы для 

 приведения типов, даже если это не предполагалось.

 * Не всегда очевидно, к какому типу данных должно выполняться приведение, 

 особенно в том случае, если несколько типов обеспечивают неявное преобразование.

 * Списки инициализации могут испытывать те же проблемы, особенно в случае, если 

 в списке один единственный элемент.

_Вывод:_

Операторы преобразования типов и конструкторы с одним элементом должны быть 

объявлены как `explicit` в определении классов. Конструкторы копирования и 

перемещения не должны быть `explicit`, поскольку они не осуществляют приведение 

типов. 

Неявное преобразование типов может иногда быть необходимы для типов, которые 

должны быть взаимозаменяемыми. Подобные вопросы должны быть согласованы с

 начальством.

Конструкторы с несколькими параметрами могут не использовать `explicit`. 

Конструкторы, которые используют один параметр `std::initializer_list` 

не должны использовать `explicit` для поддержки инициализации присваиванием 

`MyType m = {1, 2};`.

### Копируемые и перемещаемые типы данных

В публичном API класса должно быть явно указано, является ли класс копируемым,

перемещаемым, или ни тем, ни другим. Поддержка копирования или перемещения 

должна осуществляться, если она имеет смысл для этого типа данных.

*Перемещаемый (movable)* тип может быть инициализирован временным объектом или 

ему может быть присвоен временный объект.

*Копируемый (copyable)* тип может быть инициализирован другим объектом такого же

типа или присвоен ему с оговоркой, что исходный объект не должен изменяться. Тип

`std::unique_ptr`, например, является перемещаемым, но не копируемым. Типы 

данных `int` или `std::string` - это примеры типов данных, которые являются

перемещаемыми и копируемыми. 

Для пользовательских типов данных поведение при копировании определяется в 

*конструкторе копирования (copy constructor)* и в 

*операторе присваивания с копированием (copy-assignment operator)*. 

Поведение при перемещении определяется в 

*конструкторе перемещения (move constructor)* и в 

*операторе присваивания с перемещением (move-assignment operator)*, если они 

присутствуют, либо поведением при копировании в противном случае.

Конструкторы копирования/перемещения могут быть вызваны компилятором неявно. 

Например, в случае передачи в функцию по значению.

Объекты копируемых и перемещаемых типов могут быть переданы и возвращены по 

значению, что делает API проще, безопаснее и универсальнее. В отличие от 

передачи объектов через указатель или ссылку, нет риска запутаться с временем 

жизни, владением, изменчивостью и подобными рисками. Также это предотвращает 

нелокальное взаимодействие между клиентом и реализацией API, что существенно 

упрощает понимание, поддержку кода, а также его оптимизацию компилятором. Такие 

объекты  можно использовать с любым API, для которого необходима передача по 

значению. Например, контейнеры.

Конструкторы копирования/перемещения и операторы присваивания проще в 

определении, чем специальные функции, по типу `Clone()`, `CopyFrom()`, `Swap()`, 

потому что они могут быть сгенерированы компилятором, в том числе, неявно. Они 

более эффективны, поскольку не требуют выделения памяти на куче, дополнительных 

присвоений и хорошо оптимизируются.

Операции перемещения позволяют неявно и эффективно управлять передачей ресурсов 

через rvalue-объекты. Это позволяет делать код проще.

Некоторым типам не требуется быть копируемыми, а предоставление операций 

копирования для таких типов может быть запутанным, нелогичным или неверно 

понятым. Синглтоны, объекты, привязанные к специфической области видимости 

(например, `Cleanup`) или сильно связанные с уникальными данными, например 

(`Mutex`), не могут быть копируемыми по своему смыслу. Операции копирования для 

базовых классов, имеющих наследников, может перевести к *object slicing*'у - 

когда свойства из базового класса копируются, а свойства из производного - нет.

Конструкторы копирования вызываются неявно, поэтому их выполнение легко упустить 

из виду. Это может привести, например, к снижению производительности из-за 

лишнего копирования данных.

Интерфейс каждого класса должен явно определять, какие операции копирования или 

перемещения класс поддерживает. Это достигается путем явного объявления или 

удаления (с помощью ключевого слова `delete`) соответствующих операторов в 

секции `public`. 

В частности, копируемые классы должны явно объявлять операции копирования, а 

перемещаемые - операции перемещения. В некопируемыех и неперемещаемых классах 

соответствующие операторы должны быть явным образом удалены. Копируемый класс 

может также объявить операторы перемещения для поддержки более эффективного 

способа передачи данных. При объявлении оператора присваивания копирования или 

перемещения должен быть реализован соответствующий конструктор.

```c++

class Copyable {

public:

    Copyable(const Copyable& other) = default;

    Copyable& operator=(const Copyable& other) = default;

    // Неявное определение операций перемещения будет запрещено 

    // (т.к. объявлено копирование).

    // Можно определить соответствующие операции явно.

};

class MoveOnly {

public:

    MoveOnly(MoveOnly&& other);

    MoveOnly& operator=(MoveOnly&& other);

    // Неявно определённые операции копирования удаляются. 

    // Но (если хотите) можно это записать

    MoveOnly(const MoveOnly&) = delete;

    MoveOnly& operator=(const MoveOnly&) = delete;

};

class NotCopyableOrMovable {

public:

    // Такое объявление запрещает и копирование и перемещение

    NotCopyableOrMovable(const NotCopyableOrMovable&) = delete;

    NotCopyableOrMovable& operator=(const NotCopyableOrMovable&) = delete;

    // Хотя операции перемещения запрещены (неявно), можно записать это явно:

    NotCopyableOrMovable(NotCopyableOrMovable&&) = delete;

    NotCopyableOrMovable& operator=(NotCopyableOrMovable&&) = delete;

};

```

Описываемые объявления или удаления функций можно опустить в очевидных случаях:

 * Если класс не содержит секции `private` например, структура или 

 класс-интерфейс, то копируемость и перемещаемость определяется копируемостью и

 перемещаемостью всех открытых членов.

 * Если базовый класс явно некопируемый и неперемещаемый, наследные классы будут

 такими же. Однако, если базовый класс не объявляет это операции, то этого будет

 недостаточно для прояснения свойств наследуемых классов.

 * _На заметку:_ Если конструктор копирования или оператор присваивания 

 объявлен/удалён, то нужно и явно объявить/удалить оператор копирования, 

 поскольку его статус неочевиден. Аналогично и для операций перемещения.

Тип не должен быть копируемым/перемещаемым, если смысл данных операций 

неочевиден пользователю, или если его реализация влечет к большим затратам. 

Операции перемещения для копируемых типов нужны только для оптимизации 

производительности и являются потенциальным источником ошибок. Определяйте их 

только в том случае, если их использование значительно более эффективно, чем 

использование операций копирования. Желательно, чтобы для копирования и 

перемещения использовались функции по-умолчанию. Если они используются - 

обязательно проверьте, что они работают корректно.

Из-за риска слайсинга стоит избегать открытых операторов копирования и 

перемещения для классов, которые планируется использовать в качестве базовых, и 

не наследовать классы от классов с оператором присваивания. Старайтесь 

наследовать свои классы только от *чистых абстрактных (pure abstract)*.

### Структуры против классов

Используйте структуры только для пассивных объектов, предназначенных для 

хранения данных. Во всех остальных случаях используйте классы.

Ключевые слова `struct` и `class` в языке C++ практически идентичны, но мы 

вводим дополнительную семантику для этих ключевых слов. 

Структуры должны использоваться для пассивных объектов, предназначенных для 

хранения данных. Структуры могут иметь константы. Структуры не должны содержать

инварианты, которые характеризуют отношения между полями, поскольку прямой 

доступ к полям может их нарушить. Могут присутствовать конструкторы, 

деструкторы и методы-помощники, но они не должны создавать инвариантов.

Если сомневаетесь, используйте `class`.

Для единообразия с STL для `stateless`-типов можно использовать `struct`.

Например, `type_traits` и некоторые функторы.

Не забывайте о том, что у структур и классов разные 

[правила об именовании](#Имена-переменных).

### Структуры против пар и кортежей

Когда элементы в наборе могут иметь содержательные названия, использование 

структур является более предпочтительным, чем кортежи или пары.

Хотя использование кортежей и пар позволяет избежать создания пользовательского 

типа для хранения набора разнотипных данных, доступ к элементам структуры с 

осмысленными названиями лучше *читается*, чем `std::get<X>` или 

`.first`, `.second`. Хотя C++14 позволяет обращаться к элементам кортежа по 

типу, если он уникален, поля структур намного более информативны.

Пары и кортежи имеет смысл использовать там, где нет больших различий между 

полями кортежа или для работ с существующим кодом или API.

### Наследование

*Композиция* часто предпочтительнее наследования. Когда используете наследование, 

делайте его открытым (`public`). 

Когда подкласс наследуется от базового класса, он включает все определения всех 

данных и операций, определенных в базовом классе. 

*Наследованием интерфейса (Interface Inheritance)* будем называть наследование 

от *чистого абстрактного базового класса (pure abstract base class)* (без 

определенных функций и состояния). Любое другое наследование будем называть 

*Наследованием реализации (implementation inheritance)*.

*Наследование реализации* уменьшает размер кода путем повторного использования 

кода базового класса путем специализации существующего типа. Поскольку 

наследование выполняется в процессе компиляции, программист и компилятор могут 

понять операции и обнаружить ошибки. *Наследование интерфейса* может быть 

использовано глобально для того, чтобы программно гарантировать, что класс 

экспортирует определенный API. Опять же, в данном случае компилятор может в 

данном случае обнаружить ошибки в том случае, если класс не определяет нужный 

метод API.

Код, использующий *наследование реализации* становится менее понятным, 

поскольку реализация методов размазывается между базовым и дочерними классами. 

Дочерний класс не может переопределить невиртуальные функции.

Множественное наследование особенно проблематично, поскольку часто влечет за

собой большие накладные расходы по производительности и риски ромбовидного 

наследования (*diamond inheritance*), которое может повлечь за собой баги, 

неопределенность и путаницу.

Любое наследование должно быть открытым (*public*). Если у вас возникает 

потребность в закрытом наследовании, то необходимо создать закрытый член класса 

который вы хотите сделать базовым. Можно использовать ключевое слово `final` на 

классах, наследование от которых должно быть запрещено.

Не злоупотребляйте *наследованием реализации*. Композиция часто является более 

предпочтительной. Используйте семантику *является*. Класс `Bar` стоит 

наследовать от `Foo`, если можно дать утвердительный ответ на вопрос `Bar` 

является `Foo`?

Ограничьте использование защищенных (`protected`) функций, которые должны быть 

доступны подклассам. Помните, [данные должны быть закрытыми](#Контроль-доступа) 

(`private`).

Множественное наследование разрешено, но множественное *наследование реализации* 

не рекомендуется.

### Перегрузка операторов

Перегружайте операторы в рамках разумного. Не используйте пользовательские 

литералы.

С++ позволяет программисту определять своим версии встроенных операторов, 

используя для этого ключевое слово `operator` и пользовательский тип, 

как один из параметров. Также ключевое слово `operator` позволяет создавать 

пользовательские литералы, используя `operator""` и операторы приведения типов, 

например `operator bool()`. Это называется *перегрузкой операторов*.

Использование перегрузки операторов может сделать код более выразительным и 

интуитивным, когда пользовательские типы ведут себя как встроенные. 

Перегружаемые операторы соответствуют определенным операциям и следование логике 

применения этой операции может сделать работу с пользовательскими типами более 

читаемой, а также использовать их при работе с библиотеками, которые используют 

данные операторы.

Пользовательские литералы - это выразительный способ создания объектов 

пользовательских типов.

 * Предоставление корректного, согласованного и логичного набора операторов для 

 пользовательского типа требует усилий и может обернуться запутыванием и багами.

 * Злоупотребление перегрузкой операторов может привести к непонятному коду, 

 особенно, если эти семантика данных операторов не соответствует общепринятой.

  * Все проблемы, связанные с перегрузкой функций распространяются и на 

  перегрузку операторов.

 * Перегрузка операторов может быть не интуитивной в плане производительности, 

 поскольку встроенные операции очень производительны.

 * Поиск в коде вызовов перегруженных операций требует особых утилит поиска, 

 понимающих синтаксис C++.

 * Если запутаться с типами операндов перегружаемых операций, можно получить 

 другой перегруженный оператор, а не ошибку компиляции, например `foo < bar` и 

 `&foo < &bar`.

 * Перегрузка некоторых операторов является раскованной сама по себе. Например, 

 перегрузка унарного `&`. Перегрузка операторов `&&`, `||`, `,` не порядку 

 исполнения встроенных операций.

 * Операторы могут определяться вне класса, поэтому есть риск того, что разные 

 файлы могут содержать разное определение одного и того же оператора. Это может 

 привести к трудноуловимым ошибкам времени исполнения.

 * Пользовательские литералы создают новые синтаксические формы, которые будут 

 незнакомы даже продвинутым программистам. Например: `"Hello World"sv` как 

 сокращение для `std::string_view(«Hello World»)`. 

 * Т. к. для пользовательских литералов не указывается пространство имен, 

 придется использовать либо using-директиву, 

 [которая запрещена](#Пространства-Имен), либо using-объявление, запрещенное в 

 заголовочных файлах. 

_Выводы:_

Используйте перегрузку операторов только тогда, когда их значение очевидно, 

предсказуемо и согласовано со встроенными операциями. Например, переопределяйте 

оператор `|` как логическое `ИЛИ`, а не как перенаправление потока. 

Перегружайте операторы только для своих типов данных. Определяйте их в той же 

паре `.hpp`/`.cpp` - файлов, что и тип данных, к которому они относятся. Таким 

образом операции будут доступны тогда же, когда и исходный тип данных, а риск 

нескольких определений операторов будет минимизирован. По возможности избегайте 

определения шаблонных (`template`) операторов, поскольку они должны 

соответствовать определенным правилам для всех аргументов. При перегрузке 

операторов, перегружайте все связанные операторы, например, при перегрузке 

оператора `<`, необходимо перегрузить все операторы сравнения. Убедитесь, что 

они работают согласовано. Например, что операторы `<` и `>` 

никогда не возвращают `true` одновременно.

По возможности, не делайте перегруженные операторы функциями-членами классов. 

Если бинарный операнд определен как член класса, риски неявного преобразования 

существуют только для правого оператора, а если как глобальная функция - для 

обоих. Будет странно, если `a < b` компилируется, а `b > a` - нет.

Не заходите слишком далеко, избегая перегрузки операторов. Перегрузка 

операторов предпочтительнее, чем функции, по типу 

`equals(), copyFrom(), printTo()`. И наоборот, не перегружайте оператор только 

из-за того, что он нужен какой-то библиотеке. Например, если вы хотите 

использовать `std::set` для типа, для которого не предусмотрено логикой 

операций больше или меньше, используйте свою функцию-компаратор вместо 

перегрузки оператора `<`.

Не перегружайте операторы `&&, ||, ,(запятая)` и унарный `&`. 

Не используйте пользовательские литералы. 

Операторы преобразования типов обсуждаются и в секции про 

[неявное преобразование типов](#неявное-преобразование-типов). 

Оператор `=` затрагивается в секции про 

[конструкторы копирования](#копируемые-и-перемещаемые-типы-данных). 

Перегрузка оператора `<<` затрагивается в секции про 

[потоки](#потоки-ввода-вывода). Также обратите внимание не секцию про

[перегрузку функций](#перегрузка-функций), которая затрагивает перегрузку в 

целом.

### Контроль доступа

Члены-данные класса должны быть закрытыми (`private`), если это не константы 

(`const`). Это упрощает работу с инвариантами ценой создания простых 

клишированных функций (get/set-ассессоров), если не обходимо.

По техническим причинам члены данных фикстур для Google Test могут быть 

`protected`.

### Порядок объявления

Группируйте похожие объявления.

Определение класса обычно начинается с секции `public:`, за которой следует 

`protected:`, а в конце - `private:`. Избегайте пустых секций.

Внутри каждой секции группируйте похожие виды объявлений вместе. 

Предпочтительным является такой порядок:

 1. Типы данных и псевдонимы (`typedef`, `using`, `enum`, вложенные 

 структуры и классы, `friend`-типы данных).

 2. Статические константны.

 3. Фабричные методы

 4. Конструкторы и операторы присваивания

 5. Деструктор

 6. Все остальные функции (статические и нестатические функции-члены, 

 дружественные функции).

 7. Свойства класса (Члены-данные) (статические и нет).

Не размещайте определения больших методов внутри классов. Обычно только 

тривиальные или критичные к производительности функции могут быть определены 

как `inline`. См. [здесь](#inline-функции).

## Функции

### Входные и выходные данные

Как правило, выходные данные функции предоставляются через возвращаемое 

значение, иногда через выходные (или входные-выходные) параметры.

Использование возвращаемых значений предпочтительнее, поскольку они улучшают 

читаемость, при этом часто демонстрируя такую же или лучшую производительность.

Возвращение значения предпочтительно, если не получается, используйте 

возвращение по ссылке. Избегайте использования возвращения по указателю, 

если тот не может быть `null`.

Параметры функций могут быть входными, выходными или и теми, и другими. 

Обязательные входные параметры, как правило, передаются по значению или 

константной ссылке. Выходные параметры должны передаваться по неконстантной

ссылке, если они не могут быть `null`. В общем случае, используйте 

`std::optional` для необязательных входных параметров и константный указатель, 

если обязательный параметр был бы ссылкой (поскольку он `nullable`). 

Используйте неконстантные указателя для необязательных выходных или 

входных-выходных параметров.

Избегайте использований константных ссылок **только** для того, чтобы продлить

время жизни временных объектов (константные ссылки могут расширять время жизни 

и могут быть привязаны к временным объектам). Вместо этого постарайтесь найти 

способ избавиться от требований к времени жизни путем копирования объекта или 

используйте указатель, задокументировав время жизни и требования к тому, чтобы 

он не был `null`.

При объявлении параметров функции старайтесь сначала объявлять входные 

параметры функций, а потом выходные. Это не жесткое правило.

### Пишите короткие функции

Пишите короткие и концентрированные функции.

> *Функция должна делать одну вещь и делать ее хорошо!* - (c) Дядя Боб.

Иногда длинная функция бывает полезной, но если размер функции превышает 40 

строк - это повод задуматься над тем, чтобы разбить ее на несколько.

Длинные функции тяжело читаются и сложнее отлаживаются. С длинными функциями 

сложнее работать в команде, поскольку будут возникать проблемы при слиянии. 

Короткие функции легче тестировать.

При работе со старыми функциями, которые кажутся слишком длинными и запутанными, 

не бойтесь ее модифицировать: если работа с такой функцией затруднена или 

неудобна, если в ней есть ошибки, которые трудно отлаживать или если кусочки 

данной функции можно применить в другом месте, не бойтесь разбивать ее на 

меньшие и более управляемые куски.

Как правило, функция должна иметь не более 3х параметров. Особенно, если она 

экспортируется из API. Существуют исключения, например, когда функцию совершенно 

необходимо сделать `stateless`, но это "дурно пахнет".

### Перегрузка функций

Используйте перегрузку функций (в т. ч., конструкторов) только если читатель, 

смотря на код ее вызова будет хорошо понимать, что происходит без точного 

определения, какая именно перегрузка вызывается.