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