From 1606233e7e662e05063609e119d2505a606eb343 Mon Sep 17 00:00:00 2001 From: DenisKolodich Date: Mon, 1 Sep 2025 23:09:17 +0300 Subject: [PATCH] =?UTF-8?q?=D0=94=D0=BE=D0=BF=D0=BE=D0=BB=D0=BD=D0=B5?= =?UTF-8?q?=D0=BD=D0=B8=D1=8F=20=D0=B8=20=D0=BF=D1=80=D0=B0=D0=B2=D0=BA?= =?UTF-8?q?=D0=B8?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Дополнил информацией про арифметические выражения --- .../1/0__principy_chistogo_koda/article.md | 44 +++++++++++++------ .../1/0__principy_chistogo_koda/practice.md | 3 +- .../1/0__principy_chistogo_koda/reference.md | 3 +- 3 files changed, 33 insertions(+), 17 deletions(-) diff --git a/sandbox/1/0__principy_chistogo_koda/article.md b/sandbox/1/0__principy_chistogo_koda/article.md index 53f2464..ee1f3ad 100644 --- a/sandbox/1/0__principy_chistogo_koda/article.md +++ b/sandbox/1/0__principy_chistogo_koda/article.md @@ -2,7 +2,7 @@ ### Введение -Давайте поговорим о понятии чистого кода. Как вы кодируете? Это простой вопрос, но очень важный. Строите ли вы план, когда его пишете, или он рождается сам собой в процессе написания? Задумываетесь ли вы над названиями переменных, отступах и комментариях или пишете, как есть, оставляя вопросы стиля и читаемости до лучших времён? Ну и наконец, случалось ли вам при виде своего кода, написанного несколько месяцев назад, задаваться вопросом: “Что я здесь чёрт побери написал?” Если да, то этот урок для вас. +Давайте поговорим о понятии чистого кода. Как вы пишете код? Это простой вопрос, но очень важный. Строите ли вы план, когда его пишете, или он рождается сам собой в процессе написания? Задумываетесь ли вы над названиями переменных, отступах и комментариях или пишете, как есть, оставляя вопросы стиля и читаемости до лучших времён? Ну и наконец, случалось ли вам при виде своего кода, написанного несколько месяцев назад, задаваться вопросом: “Что я здесь чёрт побери написал?” Если да, то этот урок для вас. Чтобы продемонстрировать разницу между чистым и не очень чистым кодом, взгляните на следующие два примера. Листинг 1. Пример плохого кода @@ -59,7 +59,7 @@ int main(void) % **Важно!** Всегда помните, что в первую очередь код должен быть понятен другим программистам. -### Отступы - увидеть суть +### Отступы -- увидеть суть Правильная расстановка отступов позволяет разработчику быстро оценить общую структуру кода. Например, становится ясна вложенность циклов и область видимости переменных. В большинстве случаев рекомендуется смещать каждое вложение на 4 пробела вправо. Если есть второй уровень вложенности, то уже 8 пробелов. Обратите внимание на организацию отступов в листинге 3. @@ -68,16 +68,21 @@ int main(void) ```c #include -int main() { +int main() +{ int x = 10; - if (x > 5) { + if (x > 5) + { printf("x больше 5\n"); - if (x < 15) { + if (x < 15) + { printf("x меньше 15\n"); } - } else { + } + else + { printf("x не больше 5\n"); } @@ -127,7 +132,7 @@ int main(void) Уже гораздо солиднее, согласитесь. Теперь структура кода и вложенность операторов стали более наглядными. Переходим к следующему шагу. -### Имена переменных – говорить на понятном языке +### Имена переменных –- говорить на понятном языке Имя переменной должно отвечать на вопрос как она используется. Иными словами, в имени должен быть заключён смысл её существования. @@ -160,24 +165,35 @@ int s=0, d=0, h=0, m=0, hind=24, secinh=3600; ``` Тут без ста грамм не разберёшься. Чтобы понять, что делают переменные `d` и `s`, приходится постоянно обращаться к объявлениям `secinh` и `hind`. Здесь будет очень уместна цитата из книги Роберта Мартина «Чистый код»: нет худшей причины для выбора имени `c`, чем та, что имена `a` и `b` уже заняты. + Вы можете возразить: «`secinh` – хорошее имя, оно обозначает `sec in hour`, то есть количество секунд в одном часе!». Наверное, так действительно можно расшифровать. Но очевидное ли это название для человека, который первый раз смотрит на код? Что мешает программисту расписать переменную как `seconds_in_hour`? Конечно, название стало длиннее, но теперь полностью ясен смысл переменной и не возникает дополнительных вопросов. Код становится более читаемым и понятным, что значительно облегчает его поддержку и модификацию. % **Важно!** Не бойтесь использовать длинные и описательные имена переменных. Важно, чтобы название максимально точно отражало смысл переменной и её роль в программе, даже если это приводит к увеличению длины кода. -#### Стили +Стоит затронуть и тему оформления арифметических выражений. Операции, имеющие более высокий приоритет, пишутся слитно, в то время как операции более низкого приоритета -- с пробельными оступаими. Это позволяет программисту визуально оценить последовательность вычисления операторов. Посмотрите на листинг с примерами: + +Листинг 6. Примеры арифметических выражений + +```c +b*b + 4*a*c; // Сначала умножение, затем сложение +(num_1*num_2) / (num_3*num_4); // В первую очередь вычисляются выражения в числителе и знаменателе +(-b + determinant) / (2*a); // В данном случае знак + в числителе разделён пробелами для улучшения читаемости +``` + +#### Немного о стилях Ещё несколько слов об именовании переменных. Существуют два основных стиля именования переменных. 1. *CamelCase*. В этом стиле, если переменная состоит из нескольких слов, каждое новое прописывается с заглавной буквы. Это название связано с тем, что заглавные буквы создают визуальное впечатление “горбов”, как у верблюда. При этом первое слово может как начинаться с заглавной, так и с прописной буквы. Вот несколько примеров: `DayInMonth`, `NumberTables`, `SecondsPassedFromFirstShot`. 2. *snake_case*. В отличие от CamelCase, слова разделяются нижним подчёркиванием, и все буквы обычно строчные. Такое название связано с тем, что нижние подчеркивания визуально напоминают изгибы змеи. Вот также несколько примеров использования на тех же именах: `days_in_month`, `number_tables`, `second_passed_from_first_shot`. -Выбор стиля именования – вопрос личных предпочтений или соглашений, принятых в команде. Важно придерживаться выбранного стиля последовательно во всем проекте. Хотя вы можете придумать свой способ именования переменных, рекомендуется придерживаться общепринятых стилей (CamelCase или snake_case), чтобы ваш код был понятен другим разработчикам +Выбор стиля именования –- вопрос личных предпочтений или соглашений, принятых в команде. Важно придерживаться выбранного стиля последовательно во всем проекте. Хотя вы можете придумать свой способ именования переменных, рекомендуется придерживаться общепринятых стилей (CamelCase или snake_case), чтобы ваш код был понятен другим разработчикам Давайте исправим названия переменных в листинге 4. -Листинг 6. Код после наведения порядка в именах +Листинг 7. Код после наведения порядка в именах ```c #include @@ -209,13 +225,13 @@ int main(void) Применив всего два простых правила -- правильные отступы и осмысленные имена переменных, мы превратили нечитаемый код в хорошо структурированный и понятный алгоритм. -### Комментарии – говорить или молчать? +### Комментарии –- говорить или молчать? Нельзя обойти стороной и такую важную сторону, как комментарии. Они необходимы, чтобы облегчить понимание кода для других разработчиков, которые будут его читать и поддерживать. Ранее комментарии играли важную роль, особенно в командной разработке. Разработчики часто добавляли в начало файла (“шапку”) информацию об авторе, версии кода и историю изменений. Это помогало координировать работу в команде и быстро отслеживать изменения. Однако с появлением систем контроля версий (например, Git) необходимость в этих “шапках” отпала. Тем не менее, комментарии по-прежнему полезны для объяснения сложных алгоритмов, неочевидных решений, ссылок на стандарты или обоснования нестандартного подхода. Однако комментарии, дублирующие очевидный код, не несут никакой пользы и только засоряют его. -Листинг 7. Плохой пример использования комментариев. +Листинг 8. Плохой пример использования комментариев. ```c #include @@ -259,6 +275,6 @@ int main() { ***Количество преспешников стилей*** -*snake_case* *CamelCase* +*snake_case* / *CamelCase* -0 0 +0 / 0 diff --git a/sandbox/1/0__principy_chistogo_koda/practice.md b/sandbox/1/0__principy_chistogo_koda/practice.md index 31ae1ce..0eb80e3 100644 --- a/sandbox/1/0__principy_chistogo_koda/practice.md +++ b/sandbox/1/0__principy_chistogo_koda/practice.md @@ -1,3 +1,4 @@ ### Исследовательские задачи для хакеров -- Почитайте книгу А.В. Столярова "Оформление программного кода". Посмотрите, какие ещё следует соблюдать правила при именовании переменных. +-- Почитайте книгу А.В. Столярова "Оформление программного кода". Посмотрите, какие ещё следует соблюдать правила при именовании переменных. +-- Напишите в комментариях, какой стиль именования переменных вам больше понравится, а мы в этой заметке будем вести счёт. \ No newline at end of file diff --git a/sandbox/1/0__principy_chistogo_koda/reference.md b/sandbox/1/0__principy_chistogo_koda/reference.md index 48fc8d6..7018203 100644 --- a/sandbox/1/0__principy_chistogo_koda/reference.md +++ b/sandbox/1/0__principy_chistogo_koda/reference.md @@ -1,4 +1,3 @@ ## Дополнительные материалы -1. Посмотрите на то, как расположены фигурные скобки в листинге 3. Это, один из стилей оформления фигурных скобок, называемый K&R - по инициалам авторов книги Основы программирования на Си. (Kernighan и Ritchie). Поищите информацию о других стилях и напишите в комментариях какой вам понравился больше. -2. Напишите в комментариях, какой стиль именования переменных вам больше понравится, а мы в этой лекции будем вести счёт. +1. Посмотрите на то, как расположены фигурные скобки в листинге 3. Это один из популярных стилей оформления фигурных скобок, называемый K&R - по инициалам авторов книги Основы программирования на Си. (Kernighan и Ritchie). Есть, конечно, и другие стили. Например, в Allman открывающая скобка '{' всегда на новой строке, выровненная по вертикали с управляющей конструкцией.