Email or username:

Password:

Forgot your password?
Top-level
Alexey Skobkin

@kurator88
Ты же понимаешь, что комментарий выше описывает одну строку из которой и так исходит то, что в комменте?

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

Потому что комментарии устаревают и зачастую при рефакторинге не обновляются. Ты прочтёшь коммент и успокоишься. А код там уже совсем другое делает.

Но если там какая-то ёбань с регулярными выражениями, битовой магией и т.п. - можно и оставить комментарий.

7 comments
устаревший kurator88

@skobkin если у меня метод с бизнес логикой и там 5-8 блоков, то для быстрой ориентации в коде мне тоже удобно оставлять кооментарий чтобы глазами потом сразу найти Г а не вчитываться

// делаем сохраняем заявку на тикет
......
// делаем создаем новый тикет
......
// делаем запускаем обработку тикета
......
// делаем Г
......
// шлем нотификацию в другой сервис

Alexey Skobkin

@kurator88
Ну обычно если это не легаси, а писалось с расчётом на поддерживаемость, то и без комментов найти нужное место несложно.

А блоки выделяются переносами становясь как бы абзацами.

А если это легаси и мутновато написано, то тут да, применимо то, что я говорил касаемо грязных хаков.

Но я не отстаиваю, что такая ПОЧТИ радикальная позиция единственно верная.

Однако от неактуальных, бесполезных или обманывающих комментов я страдал не раз.

Blue

@kurator88@mas.to @skobkin@lor.sh эээ, названия методов/функций, не? В общем методе буквально это и написано, если надо почитать как именно делается Г прыгаем в функцию/саб/рутину "делатьГ" и читаем только её, ни на что другое не отвлекаясь, не?
если блок состоит из одной строки и из неё непонятно, что это какая-то нотификация куда-то - это хреновое апи, и если это мы сами его таким написали то не надо так его писать

устаревший kurator88

@blue @skobkin

не всегда можно бизнесс процесс поделить на функции чтобы это было удобно(блок А можно вынести в функцию но тогда она будет возвращать 3 значения etc)

тонкая грань между 'я не люблю длинные методы' и 'давайте не будем бить бизнесс-процесс на кусочки'

Blue

@kurator88@mas.to @skobkin@lor.sh вот прямо функции, что бы они что то возвращали множественное - можно, конечно, через какие-нибудь передачи в параметры выходные ссылки на переменные делать, но на моей практике их было немного, чаще всего такое бывает от недопроектирования.
Если хорошенько подумать обычно получается объединить что-то в структуру данных или взвести в своем объекте какое-то состояние, что бы не приходилось между функциями какие-то промежуточные вычисления кидать.
Другое дело про кусочный бизнесс процесс. Бизнессу, как я заметил, всегда нужно вот это вот прям ща, да, только это и ни больше ни меньше. Проходит неделя и бизнесс обычно возвращается и говорит "тут такое дело, ты там такую штуку сделал.... а можно рядом с ней еще такую же, но что бы она в середине своего потока еще сообщение в телегу отправляла что начала делать работу, а потом в конце говорила что закончила?" У меня на этом больная мозоль, уже почти десятилетие я раз за разом убеждаюсь, что чем сильнее я этот бизнесспроцесс побью на независимые куски, что бы быстро делать эти хотелки в близком к произвольному порядке - тем меньше потом создавать MyCustomAdvancedExtendedRequester объектов вот только под этот конкретный случай, только под продать и забыть, и тем меньше потом их чинить.

@kurator88@mas.to @skobkin@lor.sh вот прямо функции, что бы они что то возвращали множественное - можно, конечно, через какие-нибудь передачи в параметры выходные ссылки на переменные делать, но на моей практике их было немного, чаще всего такое бывает от недопроектирования.
Если хорошенько подумать обычно получается объединить что-то в структуру данных или взвести в своем объекте какое-то состояние, что бы не приходилось между функциями какие-то промежуточные вычисления кидать.
Другое дело про кусочный...

Alexey Skobkin

@blue @kurator88
> можно, конечно, через какие-нибудь передачи в параметры выходные ссылки

Вот бы существовал какой-нибудь паттерн про объекты для передачи данных :philosoraptor:

Blue

@skobkin@lor.sh @kurator88@mas.to да не, я как ни странно понимаю, о чем речь. Бывает такое, что есть какая-то штука которой что-то кормится, а она какой-то массив модифицирует, в какой-то другой добавляет какие-нибудь обработанные индексы из первого массива, и возвращает какие-нибудь три инта со статистикой из которых дальше по движению потока нужен один. Идти для этого писать какую-нибудь структуру из 3 интов вида РезультатОбработкиТакогоГ ради одного этого места, потом её еще тут инсатнциировать, что бы только кусочек из неё использовать это обычно в лом, потому что бизнесс процесс надо делать а не лопаты точить. Но, опять же, на моей практике, это либо от недопроектирования, неправильного разделения полномочий, либо, когда это оправдано и по другому нельзя, во всяяких... не знаю, печатая это я думал про один из моих примеров по обработке вершин на пути к отрисовке WebGL, это "точение лопат" обычно приносит пользу в долгосрочной перспективе

@skobkin@lor.sh @kurator88@mas.to да не, я как ни странно понимаю, о чем речь. Бывает такое, что есть какая-то штука которой что-то кормится, а она какой-то массив модифицирует, в какой-то другой добавляет какие-нибудь обработанные индексы из первого массива, и возвращает какие-нибудь три инта со статистикой из которых дальше по движению потока нужен один. Идти для этого писать какую-нибудь структуру из 3 интов вида РезультатОбработкиТакогоГ ради одного этого места, потом её еще тут инсатнциировать,...

Go Up