Как стать автором
Обновить

Что самое трудное в разработке программного обеспечения?

Время на прочтение13 мин
Количество просмотров8.2K
Всего голосов 20: ↑20 и ↓0+20
Комментарии31

Комментарии 31

Оч хорошая статья.

Вообще говоря, именование всего вокруг и есть то, что делает нас человеком. Сознание не может находится в семантической пустоте. Нет ничено узнанного в нашей реальности, что бы ни было поименовано.

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

Правильное именование – это и есть проявление лени. Можно было бы все переменные назвать a, b, c и так далее (кто застал бейсики на 8-битках – вспомнит), но мы находим способ облегчить себе чтение кода.

Правильная лень - поработать сейчас больше, чтобы потом пришлось работать меньше.

Смотря насколько больше сейчас и насколько меньше потом

И почему эти слова бездарные?

Фил Карлтон как-то сказал: «В информатике есть только два сложных вопроса: инвалидация кэша и присвоение имен».

Мне порой даже удивительно, насколько просто научить джуна любой технологии от веб-фреймворка до машинного зрения. Но при это невозможно ни с первого ни иногда с десятого раза донести мысль, что если функция называется doesContainerIncludeItem, то она должна возвращать Boolean и не должна ни писать в базу, ни отправлять эвенты, ни общаться с UI, ни что-то еще. Ну и наоборот, если функция проверят факт наличия чего-то в контейнере, то у тебя буквально пара вариантов ее нейминга и всего один вариант возвращаемого значения, а не бесконечный карнавал бессвязного нечитаемого бреда. До джуна из наших широт иногда еще и новозможно донести, что doesContainerIncludeItem - правильно, а isContainerIncludesItem - уже нет.

До джуна из наших широт иногда еще и новозможно донести, что doesContainerIncludeItem - правильно, а isContainerIncludesItem - уже нет.

А можно чуть подробнее, почему does правильно, а is - нет? Может есть хорошая статья на эту тему? Был бы признателен.

Насколько хорошая вам требуется статья, чтобы построить вопрос к утверждению "Container includes item" (опуская ненужные тут артикли)? Подозреваю, что это откуда-то из первого года обучения языку.

Однако не будет лишено оснований мнение, что шаблон имён предикатов, начинающийся с is, более важен в тексте программы, чем грамматика английского языка.

Согласен, вопрос договоренности. Конкретно в наших гайдах был принят более естественный подход: isCompleted, doesExist, hasProperty.

А, Вы про do_support. Тогда ок.

Потому что глагол "есть" ожидает существительного, прилагательного либо причастия, но никак не глагола. Глагол же превращается в причастие суффиксом -ing либо третьей формой, но вовсе не суффиксом -s.


Вот так будет тоже синтаксически правильно — isContainerIncludingItem, но это звучит странно. Как будто нам важно подчеркнуть что контейнер содержит элемент прямо сейчас.


Ещё есть вариант isContainerIncludedItem, но тут мне не хватает знания языка чтобы понять что именно подразумевает эта фраза. Однако, тоже не то что элемент просто лежит в контейнере.

По-моему, если топить за грамматику, то стоит учитывать где это метод будет использоваться. If, while..

Is - если что-то чем-то является

Does - если что-то что-то делает

Has - если что-то что неотъемлемо имеет.

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

Доступно. Спасибо!

Однажды на ревью кода мне попался метод isDoGetAndSet(...)

Кто первым догадается какого типа результат этого метода?

Void?

Да. Верно :)

void

Если выкрутить трэшак на максимум, то это должна быть какая-нибудь монада Either<Void, String>. Чтобы противника окончательно ввести в заблуждение.

Понимаю что речь про нейминг, но не лучше ли что-то вроде
bool Container::include(Item item) ?

Ну если это прям класс Container и вы его редактор (или вы используете Kotlin), то само собой.

Я вот от include буду ожидать изменение контейнера, как от add.


Метод проверки лучше бы назвать includes

кажется, там ни is, ни do, а has.

А еще лучше бы назвать contains

> Фил Карлтон как-то сказал: «В информатике есть только два сложных вопроса: инвалидация кэша и присвоение имен».

На самом деле он сказал «В информатике есть только два сложных вопроса: инвалидация кэша, присвоение имен и переполнение».

There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one error

Аж зубы заныли! Сейчас как раз решаю off-by-one error в программе, которую клепали 5 поколений программистов, пришедших с разных языков (плюсы, питон, джаваскрипт и т.п). С соответсвующей кашей в нейминге. На полном серьёзе хочу выкинуть и переписать всё заново, если сроки дадут

Не могу не процитировать в комментариях к такой статье известное:

Цзы Лу спросил: «Вэйский правитель намеревается привлечь Вас к управлению государством. Что Вы сделаете прежде всего»?

Учитель ответил: «Необходимо начать с исправления имен».

Цзы Лу спросил: «Вы начинаете издалека. Зачем нужно исправлять имена?»

Учитель сказал: «Как ты необразован, Ю! Благородный муж проявляет осторожность по отношению к тому, чего не знает. Если имена неправильны, то слова не имеют под собой оснований. Если слова не имеют под собой оснований, то дела не могут осуществляться. Если дела не могут осуществляться, то ритуал и музыка не процветают. Если ритуал и музыка не процветают, наказания не применяются надлежащим образом. Если наказания не применяются надлежащим образом, народ не знает, как себя вести. Поэтому благородный муж, давая имена, должен произносить их правильно, а то, что произносит, правильно осуществлять. В словах благородного мужа не должно быть ничего неправильного».

Зарегистрируйтесь на Хабре, чтобы оставить комментарий