Именование переменных, классов и методов в коде

«Имя создаваемой переменной следует выбирать так же тщательно, как имя новорождённого».

Именование переменных, классов и методов в коде — эта тема кажется простой и, пожалуй, даже не заслуживающей внимания. Все согласны, что называть переменные надо правильными именами и... И, в общем-то всё. Что такое эти правильные имена? Почему часто мы читаем чужой код и чувствуем, что его проще переписать, чем модифицировать? Почему вообще так много плохого, нечитаемого, дурно пахнущего кода появляется каждый день?

Правильный нейминг это не панацея и не серебряная пуля. Однако серьёзный подход к именованию это критически важная особенность качественного кода, равно как безответственный нейминг это наиболее частая особенность кода плохого. В чем же разница между плохим и хорошим неймингом и как научиться писать код, который не захочется через месяц выбросить? Давайте разбираться.

/****************** about ******************/

Меня зовут Алексей Голобурдин, я программирую с 2004 года и на этом канале делюсь своим опытом. Я основатель и руководитель компаний:

[Alikhan-xmxq]

Смотреть ваши видео одно удовольствие. Чисто, без воды, матов и прочего. Надеюсь произошедшая ситуация никак не повлияла на вашу работу.

[pythonbeginnerr]

Это видео будет актуально всегда!🔥
Большое Вам спасибо🫡🤝

[Olegis]

Спасибо большое за ваш труд и за то, что делитесь своими знаниями. У вас очень хороший канал, много полезной информации.

[tdigital]

Кто снимает видео в час ночи с субботы на воскресенье и выкладывает его в 5 утра, тот я. Сорян за большой тайминг:)

[antaki]

Касаемо перевода терминов, я иногда использовал такой подход. Переводчик бывает неточным и может не знать, какое именно значение слова я имею в виду. Поэтому я открывал статью в русской Википедии с нужным названием и переключал язык на английский, чтобы открыть англоязычную версию статьи. Название этой англоязычной статьи — и есть нужный мне корректный перевод слова.
На самом деле, сделать это проще и быстрее, чем объяснить :)

[mentatij]

Добавлю от себя:
- к "is_" для булевых значений добавлю часто используемое "has_" (has_child и т.п.)
- советую записать отдельно часто используемые глаголы для названий функций на английском (humanize, fetch, get, create и т.п.) - со временем список устаканится и осядет в голове
- про декомпозицию функций: моё правило - функция должна умещаться на экран или меньше (зависит от экрана)

[ldm]

Он ведь настолько крут, что его видео можно смотреть в 4k.

[Vjidowkdkcpapqkfjfw]

Алексей, спасибо! Все по делу!
Про чистый код плюсую!

[ДенисК-ря]

Оставлю самый лучший комментарий, пусть и бесмысленный, но очень нужный и важный.

[НиколайИ-дм]

Каждое видео на вес золота! Спасибо за труд!

[dmytrokorbanytskyi]

Есть еще очень хорошее правило: "длинна имени переменной должна быть пропорциональна области ее видимости". Если у вас счетчик цикла, область видимости которого одна-две строки, то длинное имя будет только загромождать код.

[dmsun]

Спасибо, после твоего видео пошел переписывать свой код

[arudskyy]

Многие упомянутые вещи очень часто входят в официальный стиль программирования принятый фирмой или проектом разработчиком. Отклонение от этого стиля на этапе контроля качества (ревью) приравнивается ошибке в коде и возвращается к разработчикам для доработки. Последний момент, комментарии "для чего" код (переменная) это очень важный и редкий зверь; программистов нужно учить этому, как и именованию, в том числе. Спасибо за хорошее изложение основополагающих элементов для высококачественных проектов!

[art]

Материал полезный, подача отличная, а за мнение по поводу комментариев в коде огромный плюс!

[mrleshiy]

3:40 Зачем нужен читаемый кот и где его взять?

[blackonyx]

Чисто субъективное наблюдение опишу тут: часто переменные типа paying_customers или paying_for_waranty_custormers, и проч. упрощают чтение отдельной строки, но при этом усложняют восприятие функции/ класса/ модуля в целом(очень много повторяющегося текста). при этом например аспект paying_for_woranty может быть понятен из контекста функции/ класса/ модуля. Для меня не понимание структуры функции/ класса/ модуля видится большей проблемой чем не понимание отдельной строки, т.к. структурные огрехи - высокоуровневые и имеют больший множитель на последствия ошибок. Такая вот мысль

[silicodance]

20:37 Может для command лучше использовать аббревиатуру cmd ?

[laklaan]

Давеча меня не взяли джуном на галеру сугубо из-за нейминга, а в книгах этому внимание не уделяется (по большей части). После данного видео (а также msdn) - стало все на свои места и пришло полное понимание. Респект автору!

[АлексейКирсанов-фй]

А можно видео на тему архитектуры? Сам испытываю огромные проблемы с тем, что сделать классом, а что сделать методом, какие есть общие правила? В команде оно понятное дело как то выстраивается, но что делать, если пишешь в одиночестве?)

[michailshultz]

Информации мало. Хотелось бы больше примеров. Можно сразу смотреть с 7:25. За видео спасибо.