Слишком много комментариев уже написали, прошу простить если повторю кого.
Примеры с handler, manager не понравились. Как раз таки удобнее когда так пишут, чем что-то более экзоческое из двух-трёх слов придумают. Вспоминать их названия, и потом отыскивать в проектах, та ещё боль.
Utils/helpers - уже другое. Есть примеры где это более чем уместно, как лишний абстрактный слой в каком-то сервисе. Но как правило, в так названных директориях всегда твориться каша. Так что тут вполне согласен.
Я полагаю новички могут читать статью. Так что пожалуй стоило бы про items и list уточнить, что это для общего кода не уместно. Если у нас есть сервисы/методы обработки какого-то бы то не было конкретного списка, при правильном имени метода, это наоборот будет излишне расписывать суть в имени переменной.
А я вот допускаю что ещё и статья в оригинале могла быть написана ИИ :)
В тексте 2022. Статья ожидала три года? Или опечатка?
Хотя может у вас и так, а я просто не в курсе :)
Слишком много комментариев уже написали, прошу простить если повторю кого.
Примеры с handler, manager не понравились. Как раз таки удобнее когда так пишут, чем что-то более экзоческое из двух-трёх слов придумают. Вспоминать их названия, и потом отыскивать в проектах, та ещё боль.
Utils/helpers - уже другое. Есть примеры где это более чем уместно, как лишний абстрактный слой в каком-то сервисе. Но как правило, в так названных директориях всегда твориться каша. Так что тут вполне согласен.
Я полагаю новички могут читать статью. Так что пожалуй стоило бы про items и list уточнить, что это для общего кода не уместно. Если у нас есть сервисы/методы обработки какого-то бы то не было конкретного списка, при правильном имени метода, это наоборот будет излишне расписывать суть в имени переменной.
Но в целом, спасибо за статью!
Это одна из целей зачем мы шли в айти, до того как это стало мэйнстримом.
Когда в комментарии больше интересной информации, чем в самой статье!
Спасибо за совет!