You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: sandbox/1/0__principy_chistogo_koda/article.md
+30-14Lines changed: 30 additions & 14 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,7 +2,7 @@
2
2
3
3
### Введение
4
4
5
-
Давайте поговорим о понятии чистого кода. Как вы кодируете? Это простой вопрос, но очень важный. Строите ли вы план, когда его пишете, или он рождается сам собой в процессе написания? Задумываетесь ли вы над названиями переменных, отступах и комментариях или пишете, как есть, оставляя вопросы стиля и читаемости до лучших времён? Ну и наконец, случалось ли вам при виде своего кода, написанного несколько месяцев назад, задаваться вопросом: “Что я здесь чёрт побери написал?” Если да, то этот урок для вас.
5
+
Давайте поговорим о понятии чистого кода. Как вы пишете код? Это простой вопрос, но очень важный. Строите ли вы план, когда его пишете, или он рождается сам собой в процессе написания? Задумываетесь ли вы над названиями переменных, отступах и комментариях или пишете, как есть, оставляя вопросы стиля и читаемости до лучших времён? Ну и наконец, случалось ли вам при виде своего кода, написанного несколько месяцев назад, задаваться вопросом: “Что я здесь чёрт побери написал?” Если да, то этот урок для вас.
6
6
Чтобы продемонстрировать разницу между чистым и не очень чистым кодом, взгляните на следующие два примера.
7
7
8
8
Листинг 1. Пример плохого кода
@@ -59,7 +59,7 @@ int main(void)
59
59
% **Важно!**
60
60
Всегда помните, что в первую очередь код должен быть понятен другим программистам.
61
61
62
-
### Отступы - увидеть суть
62
+
### Отступы -- увидеть суть
63
63
64
64
Правильная расстановка отступов позволяет разработчику быстро оценить общую структуру кода. Например, становится ясна вложенность циклов и область видимости переменных. В большинстве случаев рекомендуется смещать каждое вложение на 4 пробела вправо. Если есть второй уровень вложенности, то уже 8 пробелов. Обратите внимание на организацию отступов в листинге 3.
65
65
@@ -68,16 +68,21 @@ int main(void)
68
68
```c
69
69
#include<stdio.h>
70
70
71
-
intmain() {
71
+
intmain()
72
+
{
72
73
int x = 10;
73
74
74
-
if (x > 5) {
75
+
if (x > 5)
76
+
{
75
77
printf("x больше 5\n");
76
78
77
-
if (x < 15) {
79
+
if (x < 15)
80
+
{
78
81
printf("x меньше 15\n");
79
82
}
80
-
} else {
83
+
}
84
+
else
85
+
{
81
86
printf("x не больше 5\n");
82
87
}
83
88
@@ -127,7 +132,7 @@ int main(void)
127
132
128
133
Уже гораздо солиднее, согласитесь. Теперь структура кода и вложенность операторов стали более наглядными. Переходим к следующему шагу.
129
134
130
-
### Имена переменных – говорить на понятном языке
135
+
### Имена переменных –- говорить на понятном языке
131
136
132
137
Имя переменной должно отвечать на вопрос как она используется. Иными словами, в имени должен быть заключён смысл её существования.
Тут без ста грамм не разберёшься. Чтобы понять, что делают переменные `d` и `s`, приходится постоянно обращаться к объявлениям `secinh` и `hind`. Здесь будет очень уместна цитата из книги Роберта Мартина «Чистый код»: нет худшей причины для выбора имени `c`, чем та, что имена `a` и `b` уже заняты.
168
+
163
169
Вы можете возразить: «`secinh` – хорошее имя, оно обозначает `sec in hour`, то есть количество секунд в одном часе!». Наверное, так действительно можно расшифровать. Но очевидное ли это название для человека, который первый раз смотрит на код? Что мешает программисту расписать переменную как `seconds_in_hour`? Конечно, название стало длиннее, но теперь полностью ясен смысл переменной и не возникает дополнительных вопросов. Код становится более читаемым и понятным, что значительно облегчает его поддержку и модификацию.
164
170
165
171
% **Важно!**
166
172
Не бойтесь использовать длинные и описательные имена переменных. Важно, чтобы название максимально точно отражало смысл переменной и её роль в программе, даже если это приводит к увеличению длины кода.
167
173
168
-
#### Стили
174
+
Стоит затронуть и тему оформления арифметических выражений. Операции, имеющие более высокий приоритет, пишутся слитно, в то время как операции более низкого приоритета -- с пробельными оступаими. Это позволяет программисту визуально оценить последовательность вычисления операторов. Посмотрите на листинг с примерами:
175
+
176
+
Листинг 6. Примеры арифметических выражений
177
+
178
+
```c
179
+
b*b + 4*a*c; // Сначала умножение, затем сложение
180
+
(num_1*num_2) / (num_3*num_4); // В первую очередь вычисляются выражения в числителе и знаменателе
181
+
(-b + determinant) / (2*a); // В данном случае знак + в числителе разделён пробелами для улучшения читаемости
182
+
```
183
+
184
+
#### Немного о стилях
169
185
Ещё несколько слов об именовании переменных. Существуют два основных стиля именования переменных.
170
186
171
187
1.*CamelCase*. В этом стиле, если переменная состоит из нескольких слов, каждое новое прописывается с заглавной буквы. Это название связано с тем, что заглавные буквы создают визуальное впечатление “горбов”, как у верблюда. При этом первое слово может как начинаться с заглавной, так и с прописной буквы. Вот несколько примеров: `DayInMonth`, `NumberTables`, `SecondsPassedFromFirstShot`.
172
188
173
189
2.*snake_case*. В отличие от CamelCase, слова разделяются нижним подчёркиванием, и все буквы обычно строчные. Такое название связано с тем, что нижние подчеркивания визуально напоминают изгибы змеи. Вот также несколько примеров использования на тех же именах: `days_in_month`, `number_tables`, `second_passed_from_first_shot`.
174
190
175
-
Выбор стиля именования – вопрос личных предпочтений или соглашений, принятых в команде. Важно придерживаться выбранного стиля последовательно во всем проекте. Хотя вы можете придумать свой способ именования переменных, рекомендуется придерживаться общепринятых стилей (CamelCase или snake_case), чтобы ваш код был понятен другим разработчикам
191
+
Выбор стиля именования –- вопрос личных предпочтений или соглашений, принятых в команде. Важно придерживаться выбранного стиля последовательно во всем проекте. Хотя вы можете придумать свой способ именования переменных, рекомендуется придерживаться общепринятых стилей (CamelCase или snake_case), чтобы ваш код был понятен другим разработчикам
176
192
177
193
Давайте исправим названия переменных в листинге 4.
178
194
179
195
180
-
Листинг 6. Код после наведения порядка в именах
196
+
Листинг 7. Код после наведения порядка в именах
181
197
182
198
```c
183
199
#include<stdio.h>
@@ -209,13 +225,13 @@ int main(void)
209
225
210
226
Применив всего два простых правила -- правильные отступы и осмысленные имена переменных, мы превратили нечитаемый код в хорошо структурированный и понятный алгоритм.
211
227
212
-
### Комментарии – говорить или молчать?
228
+
### Комментарии –- говорить или молчать?
213
229
214
230
Нельзя обойти стороной и такую важную сторону, как комментарии. Они необходимы, чтобы облегчить понимание кода для других разработчиков, которые будут его читать и поддерживать. Ранее комментарии играли важную роль, особенно в командной разработке. Разработчики часто добавляли в начало файла (“шапку”) информацию об авторе, версии кода и историю изменений. Это помогало координировать работу в команде и быстро отслеживать изменения. Однако с появлением систем контроля версий (например, Git) необходимость в этих “шапках” отпала.
215
231
216
232
Тем не менее, комментарии по-прежнему полезны для объяснения сложных алгоритмов, неочевидных решений, ссылок на стандарты или обоснования нестандартного подхода. Однако комментарии, дублирующие очевидный код, не несут никакой пользы и только засоряют его.
217
233
218
-
Листинг 7. Плохой пример использования комментариев.
234
+
Листинг 8. Плохой пример использования комментариев.
1. Посмотрите на то, как расположены фигурные скобки в листинге 3. Это, один из стилей оформления фигурных скобок, называемый K&R - по инициалам авторов книги Основы программирования на Си. (Kernighan и Ritchie). Поищите информацию о других стилях и напишите в комментариях какой вам понравился больше.
4
-
2. Напишите в комментариях, какой стиль именования переменных вам больше понравится, а мы в этой лекции будем вести счёт.
3
+
1. Посмотрите на то, как расположены фигурные скобки в листинге 3. Это один из популярных стилей оформления фигурных скобок, называемый K&R - по инициалам авторов книги Основы программирования на Си. (Kernighan и Ritchie). Есть, конечно, и другие стили. Например, в Allman открывающая скобка '{' всегда на новой строке, выровненная по вертикали с управляющей конструкцией.
0 commit comments