docs(readme): обновить структуру и содержание README.md, улучшить оформление (#27)

Co-authored-by: petrovyuri <petrovyuri@example.com>

tools/rfc/RFC-documentation.md

@@ -2,25 +2,29 @@
 
 ## Документация
 
-### Основные правила ведения документации в проекте:
+### Основные правила ведения документации в проекте
+
 - документация оформляется над описываемым объектом с использованием '///';
 - документацией необходимо покрывать все классы, конструкторы, поля, геттеры, сеттеры, методы, фабрики, все кастомные объекты;
 - документация должна:
-    - указывать на назначение объекта;
-    - содержать исчерпывающее описание объекта;
-    - быть краткой и емкой;
-    - быть понятной для любого разработчика.
+  - указывать на назначение объекта;
+  - содержать исчерпывающее описание объекта;
+  - быть краткой и емкой;
+  - быть понятной для любого разработчика.
 
 ## Шаблоны и примеры документации объектов
 
-### Документация классов:
+### Документация классов
+
 ```dart
     /// {@template new_class}
     /// Класс для реализации {описание назначения и реализуемого функционала в классе}.
     /// {@endtemplate}
     class NewClass {}
 ```
+
 Пример:
+
 ```dart
     /// {@template app_button}
     /// Класс для реализации кастомизированной кнопки.
@@ -28,11 +32,12 @@
     class AppButton {}
 ```
 
-### Документация конструкторов и фабрик:
+### Документация конструкторов и фабрик
 
-Если конструктор один, то достаточно указать {@macro new_class}. 
+Если конструктор один, то достаточно указать {@macro new_class}.
 {@macro new_class} дублирует на конструктор указанную в рамках описания класса документацию, поэтому описание класса должно в таком случае включать все передаваемые в конструктор параметры
 Если конструкторов несколько, описания должны отражать их отличия друг от друга. Фабрики описываются по такому же принципу.
+
 ```dart
     ///{@macro new_class}
     const NewClass();
@@ -43,8 +48,10 @@
     factory NewClass.fromJson(Map<String, dynamic> json)
 ```
 
-### Документация полей классов:
+### Документация полей классов
+
 В классе необходимо описывать каждое поле по отдельности. Если поле ссылается на другое поле или зависит от него, необходимо это указывать в описании.
+
 ```dart
     /// Возраст пользователя.
     final int age;
@@ -53,7 +60,8 @@
     final bool isAdult;
 ```
 
-### Документация геттеров/сеттеров:
+### Документация геттеров/сеттеров
+
 ```dart
     /// Получения доступа к {описание данных, которые получает геттер}
     int get newGetter => ...
@@ -62,8 +70,10 @@
     set newSetter (int setterValue) => ...
 ```
 
-### Документация методов:
+### Документация методов
+
 Методы должны описывать их основное назначение. Если метод сложный, требуется указывать дополнительное описание его работы ниже через пропущенную строку. Если метод принимает какие-либо параметры, каждый параметр должен быть описан по отдельности списком с прямой ссылкой. Если метод возвращает какие-либо значения, они должны быть описаны. Желательно указать, что вернет метод в случае возникновения ошибки.
+
 ```dart
     /// Метод для {описание назначения метода}.
     /// {описание особенностей работы метода}.
@@ -73,7 +83,9 @@
         ...
     }
 ```
+
 Пример:
+
 ```dart
     /// Метод для расчета температуры.
     /// Принимает:
@@ -88,16 +100,20 @@
 
 ## Комментарии
 
-### Основные правила комментирования кода в проекте:
+### Основные правила комментирования кода в проекте
+
 - комментарии оформляются над описываемым участком кода с использованием '//';
 - комментировать необходимо те участки кода, которые действительно нуждаются в дополнительном описании;
 - комментарий не должен повторять легко читаемые участки кода
   
-Например: 
+Например:
+
 ```dart
  if(flag != true)  // не нужно описывать как "Если значение не равно true...
 ```
+
 Например:
+
 ```dart
  if(isAurora){
     // Так как Аврора не может открывать WebView, 
@@ -107,7 +123,8 @@
 
 ## TODO
 
-### Основные правила создания TODO в проекте:
+### Основные правила создания TODO в проекте
+
 - TODO оформляются согласно условиям форматирования линтера с указанием имени разработчика, кто находится в контексте проблемы и сможет ее прокомментировать;
 - TODO необходимо оставлять на тех участках кода, которые требуют дальнейшей доработки;
-- если известно, в рамках какой задачи будет доработан помечаемый участок кода, ссылку на задаче необходимо оставить в скобках.
+- если известно, в рамках какой задачи будет доработан помечаемый участок кода, ссылку на задаче необходимо оставить в скобках.