В 90х в СПБ была реальная компания, которая за большие бабки рисовала труп клиента, что бы должники отстали. Могли разчлененку, могли повешение прифотошопить.
Фильм Семь психопатов.
А это именно история из гифки https://www.youtube.com/watch?v=fjW3VXMdrmc
И в случае непонимания появлялся бы Капитан Очевидность. Ибо даже несмотря на минимум текста в картинке поста, я не сразу понял суть.
Если берёшься писать код с использованием английских слов, так выучи хоть этот английский сначала. Потом сидишь и пытаешься врубиться в код этих писак. Is understand?
Грамматика грамматикой, но здесь логичнее именно isUnderstand, чем isUnderstood.
Учитывая, что саму функцию придётся отдельно писать, в ней явно будут переменные и подфункции со словом «Understand» в названии. А значит, на случай, тебе придётся искать все обращения к ним в коде, проще использовать в названии одно и то же слово.
И да, комменты всем в помощь.
И да, isUnderstand — это полная бессмыслица, обычно я подобное вижу у зелёных выпускников российских ВУЗов.
Все производные от to be используются в качестве префиксов при необходимости, никаких «привычек» в нормальных проектах нет, особенно если это не локальная поделка российских разработчиков (или других неносителей английского).
Я согласен, что префикс is встречается очень часто, но он обусловлен смыслом данных, которые хранит переменная. Так что назвать переменную wasUnderstood — это абсолютно нормально.
Так же как начинать название функции с has, will, did, например. У многих как будто табу на употребление определённых слов английского языка в коде)
Если у вас в компании не принято комментировать код, чтоб было понятно его назначение, не стоит свою жопаболь транслировать на других
Эм, что?
1) Комменты на русском что ли предлагаешь писать? На английском-то они только усугубят всё.
2) Если в коде вызывается некая функция, или используется переменная/поле и они уже имеют нормальные названия, то вообще нет необходимости переходить в объявление, чтобы почитать документацию. И не надо в голове строить и хранить мапу кривое_название_функции -> что_она_делает_на_самом_деле.
3) Ну и вообще, есть мнение, что обилие комментов - антипаттерн, а код должен быть выразительным сам по себе.
1. И в чем проблема комментов на русском, если команда разработчиков русскоязычные?
2. Вполне нормальное название. Краткая форма вопроса: Understand? Или надо было писать DoYouUnderstand? Хз у кого как, а у нас бы за DoYouUnderstand на кодревью разработчик бы от лида выхватил. is - типовой признак функции возвращающей логическое значение, часто встречается в соглашении о наименованиях.
3. Ну да, когда калькулятор пишешь вполне сработает. Только вот в системах федерального уровня с 6-10 командами по 5 человек с горизонтом на 3-5 лет это ни разу не работает, потому что люди меняются и трудозатраты на разбор малокомментированного кода на порядок превышают затраты на само комментирование. Разработчику может и пофиг, но нормалный лид или менеджер за такими вещами следит и выдает живительных люлей чувакам, для которых главное не работа, а творчество и красота
3. В достаточно сложном коде и так достаточно вещей, которые стоит комментировать, чтобы засирать код еще и комментариями о том, что делают функции с нелогичными и путающими названиями.
С остальным согласен.
Сам мейнтейнер
Что же, лучше поздно, чем никогда.
1) Поскольку аглицкий, по сути, лингва франка индустрии, то нужно, наоборот, искать аргументы в пользу употребления национального языка, а не стандартного. Исходя из постулата, что все девелоперы и так уже знают английский, я затрудняюсь придумать разумную причину для использования русского. Зачем? Чтобы русскоязычная команда так и осталась русскоязычной, даже когда захочется нанять иностранцев?
2) Это вообще странный пример. Префикс is для признаков/атрибутов состояния только годится. Положим, есть какая-то хрень, которая запускается методом execute. Возвращает boolean, где true означает успешный запуск. Называть этот метод isExecute шоле теперь?
3) В этом пункте вы слегка отошли от сути моего изначального посыла. Я, кажется, выступал против обилия избыточных комментов, а не против комментирования в принципе. Малоочевидные, временные, обходные решения, допущения, всякие странности в логике и т.п. естественно нужно комментить. А все остальное должно быть понятно из самого кода. Существует же устоявшийся набор наработанных терминов, конвенций, идиом, паттернов. С комментами есть еще две беды:
а) так же, как и код, комментарии пишутся людьми, а значит так же содержат ошибки. Не грамматические, а логические.
б) рассинхронизация кода и комментариев. Ну это вообще классика: логика в коде обновилась, а в комментах это не отражено.
Ну и мне лениво переключать постоянно раскладку при написании.
Да и при чтении проще на одном языке работать, опять же.
И поиск в коде упоминаний какого-либо бизнес/тех-термина проще. А то поищи сначала "customer", а потом еще и "заказчик" на всякий случай, вдруг какой программер в комменте на русском что-то важное написал про эту сущность.
Короче, абсолютно никаких доводов пользу русского. Кроме незнания английского командой. Но я команд такого уровня избегаю.
3. Если код сложный и объемный, а работает с ним больше двух человек, объяснение где-что-как начинает отнимать нерационально много времени.