Опечатки и разметка в man2.1

Author: KaDeaT

manuals/2/0__basic_clean_code_principles/article.md

@@ -12,7 +12,7 @@
 
 Чтобы наглядно продемонстрировать разницу, давайте рассмотрим следующий пример. 
 
-% **Пример**
+> **Пример**
 Написать программу, которая определяет, является ли введённое число простым или составным.
 На вход программе можно подавать любое натуральное число, большее `1`.
 Если число простое, то программа выводит строку `prime`, иначе -- строку `composite`.
@@ -215,10 +215,11 @@ int main(void) {
 Отдельно каснёмся оформления арифметических выражений. Иногда внутри них опускают пробелы вокруг бинарных операторов, чтобы нагляднее показать структуру выражения и/или приоритет операций. Операторы, имеющие более высокий приоритет, пишут без пробелов, в то время как операторы более низкого приоритета — с пробелами вокруг. Посмотрите на следующий листинг с примерами:
 
 Листинг 7. Примеры оформления арифметических выражений 
+```c
 b*b + 4*a*c; 				   // сначала умножение, затем сложение
 (num_1*num_2) / (num_3*num_4); // сначала вычисляются выражения в числителе и знаменателе
 (-b + determinant) / (2*a);	   // добавили пробелы вокруг + для улучшения читаемости
-
+```
 
 ## Имена переменных
 
@@ -328,15 +329,15 @@ int main(void)
 Даже видя условие задачи, я не сразу сообразил, что за магические числа `4990` и `8.317e+24`. 
 
 
-Итак, применив всего несколько простых принципов, мы превратили нечитаемый код в хорошо структурированный и понятный чистый код.
+Итак, применив всего несколько простых принципов, мы превратили нечитаемую портянку инструкций языка Си в хорошо структурированный и понятный код.
 
 ## Комментарии — говорить или молчать?
 
-Комментарии необходимы, чтобы облегчить понимание кода другим програмистам, которые будут его читать и поддерживать. 
+Комментарии необходимы чтобы облегчить понимание кода другим програмистам, которые будут его читать и поддерживать. 
 
-Раньше разработчики часто добавляли в начало файла (“шапку”) информацию об авторе, версии кода и историю изменений. Это помогало координировать работу в команде и отслеживать изменения. Однако с появлением =систем управления версиями= (например, Git) необходимость в этих “шапках” отпала.
+Раньше разработчики часто использовали комментарии для добавления в начало файла (“шапку”) информации об авторе, версии программы, историю изменений и контактных данных. Это помогало координировать работу в команде и отслеживать изменения. Однако с появлением =систем управления версиями= (например, Git) необходимость в подобных “шапках” резко сократилась.
 
-Тем не менее, комментарии по-прежнему полезны для объяснения сложных алгоритмов, неочевидных решений, ссылок на стандарты или обоснования нестандартного подхода. Однако комментарии, дублирующие очевидный код, не несут никакой пользы и только засоряют его.
+Тем не менее, комментарии по-прежнему полезны для объяснения сложных алгоритмов, неочевидных решений, ссылок на стандарты или объяснения нестандартных решений и трюков. Однако комментарии, дублирующие очевидный код, не несут никакой пользы и только засоряют его.
 
 Листинг 11. Плохой пример использования комментариев
 ```c
@@ -358,6 +359,7 @@ int main() {
     return 0;
 }
 ```
+
 Здесь нет ни одного полезного комментария. Эти комментарии лишь описывают очевидный код и не добавляют никакой новой информации, а наоборот, затрудняют чтение. Такие комментарии на зачётах по программированию используют нерадивые студенты, которым программу написал друг или генеративный искусственный интеллект. Им они действительно нужны, т.к. для них комментируемый код зачастую не является очевидным. =)
 
 % **Принцип 7:** Избегайте избыточных и тривиальных комментариев, которые не несут полезной информации.
@@ -366,7 +368,7 @@ int main() {
 
 Чтобы проиллюстрировать разумное использование комментариев, давайте усовершенствуем программу из Листинг 2 (или Листинга 9) следующим образом:
 
-Листинг 12. 
+Листинг 12. Добавим в Листинг 9 математический трюк для оптимизации перебора
 ```c
 #include <stdio.h>