Fixed formatting [#METR-2944].

doc/style_ru.md

@@ -335,9 +335,9 @@ enum class CompressionMethod
 В свою очередь, в библиотечном коде, оператор delete можно использовать только в деструкторах.
 В прикладном коде следует делать так, что память освобождается каким-либо объектом, который владеет ей.
 Примеры:
-- проще всего разместить объект на стеке, или сделать его членом другого класса.
-- для большого количества маленьких объектов используйте контейнеры.
-- для автоматического освобождения маленького количества объектов, выделенных на куче, используйте shared_ptr/unique_ptr.
+ * проще всего разместить объект на стеке, или сделать его членом другого класса.
+ * для большого количества маленьких объектов используйте контейнеры.
+ * для автоматического освобождения маленького количества объектов, выделенных на куче, используйте shared_ptr/unique_ptr.
 
 2. Управление ресурсами.
 Используйте RAII и см. пункт выше.
@@ -385,10 +385,10 @@ assert-ы не используются.
 5. Исключения, вылетающие из деструкторов.
 Использовать не рекомендуется, но допустимо.
 Используйте следующие варианты:
-5.1. Сделайте функцию (done() или finalize()), которая позволяет заранее выполнить всю работу, в процессе которой может возникнуть исключение. Если эта функция была вызвана, то затем в деструкторе не должно возникать исключений.
-5.2. Слишком сложную работу (например, отправку данных по сети) можно вообще не делать в деструкторе, рассчитывая, что пользователь заранее позовёт метод для завершения работы.
-5.3. Если в деструкторе возникло исключение, желательно не "проглатывать" его, а вывести информацию в лог (если в этом месте доступен логгер).
-5.4. В простых программах, если соответствующие исключения не ловятся, и приводят к завершению работы с записью информации в лог, можно не беспокоиться об исключениях, вылетающих из деструкторов, так как вызов std::terminate (в случае noexcept по-умолчанию в C++11), является приемлимым способом обработки исключения.
+ * Сделайте функцию (done() или finalize()), которая позволяет заранее выполнить всю работу, в процессе которой может возникнуть исключение. Если эта функция была вызвана, то затем в деструкторе не должно возникать исключений.
+ * Слишком сложную работу (например, отправку данных по сети) можно вообще не делать в деструкторе, рассчитывая, что пользователь заранее позовёт метод для завершения работы.
+ * Если в деструкторе возникло исключение, желательно не "проглатывать" его, а вывести информацию в лог (если в этом месте доступен логгер).
+ * В простых программах, если соответствующие исключения не ловятся, и приводят к завершению работы с записью информации в лог, можно не беспокоиться об исключениях, вылетающих из деструкторов, так как вызов std::terminate (в случае noexcept по-умолчанию в C++11), является приемлимым способом обработки исключения.
 
 
 6. Отдельные блоки кода.
@@ -407,11 +407,11 @@ ready_any.set();
 
 7. Многопоточность.
 В программах offline обработки данных:
-- cначала добейтесь более-менее максимальной производительности на одном процессорном ядре;
-- потом можно распараллеливать код, но только если есть необходимость.
+ * cначала добейтесь более-менее максимальной производительности на одном процессорном ядре;
+ * потом можно распараллеливать код, но только если есть необходимость.
 В программах - серверах:
-- используйте пул потоков для обработки запросов;
-- на данный момент, у нас не было задач, в которых была бы необходимость использовать userspace context switching.
+ * используйте пул потоков для обработки запросов;
+ * на данный момент, у нас не было задач, в которых была бы необходимость использовать userspace context switching.
 Fork для распараллеливания не используется.
 
 8. Синхронизация потоков.