Z
Я когда пишу обработки которые используют типовые вызовы просто в шапке описываю что использовалось если обработка или расширение автономны.
Size: a a a
2021 March 31
АМ
Я когда пишу обработки которые используют типовые вызовы просто в шапке описываю что использовалось если обработка или расширение автономны.
Ясно. Интересный вариант. Спасибо.
Z
Z
вот так например
АМ
Еще спрошу про комментарии. Ранее мучали вариант, когда доработки оформляются открывающим и закрывающим комментарием. С указанием задачи, даты, ФИО и т.п. В случае добавления это были просто комментарии, в случае изменения - закомментированный прошлый код и новый, все вместе обрамленное комментариями, в случае удаления - закомментированный код. Некий аналог диффа внутри кода модуля :) Сейчас это все стало конкретно утомлять :) Комментариев набирается в разы больше кода. В типовых модулях это еще имеет смысл кмк для удобства обновления на новый типовой релиз, а вот в нетиповых объектах хочу отказаться от комментариев (кроме смысловых конечно и заголовков функций) вовсе. Это нормальная практика?
AS
Ненормальная практика - оставлять такие комментарии. ИМХО это все со времен 7.7 тянется, где даже хранилища не было.
Z
Лучше использовать хранилище и гит.
АМ
Лучше использовать хранилище и гит.
Так одно другому вроде не мешает. Меня интересуют именно комментарии в коде.
Z
Такие комментарии бывают удобны при сравнении обновлении при обновлении типовой. В таких случаях можно писать открывающий закрывающий. А фио дата и что там ещё врядли кому то интересны.
NG
Такие комментарии бывают удобны при сравнении обновлении при обновлении типовой. В таких случаях можно писать открывающий закрывающий. А фио дата и что там ещё врядли кому то интересны.
Трехстороннее сравнение в kdiff, и авторские комментарии не нужны
AS
удобно же
АМ
Трехстороннее сравнение в kdiff, и авторские комментарии не нужны
Ну то есть даже в типовых модулях можно не оставлять комментарии вставок? А насколько удобно будет обновляться при этом? kdiff не всегда помогает в случае массового переноса функций и процедур, так как цепляется за строки без учета структуры модуля
АМ
Да, такое тоже практикуем, но во внешних отчетах и обработках
АМ
Такие комментарии бывают удобны при сравнении обновлении при обновлении типовой. В таких случаях можно писать открывающий закрывающий. А фио дата и что там ещё врядли кому то интересны.
То есть при разборе инцидентов пользоваться отчетами о сравнении хранилища или дифф в гите, а в коде оставлять только метки для обновления и смысловые комментарии?
AS
А на недоуменные взгляды надо говорить "Все есть код, йопт"
АМ
А на недоуменные взгляды надо говорить "Все есть код, йопт"
Если бы платили за строчки :)
Z
Александр Медведько
Да, такое тоже практикуем, но во внешних отчетах и обработках
Лучше класть в гит и писать ченджлог в маркдаун)
АМ
Лучше класть в гит и писать ченджлог в маркдаун)
т.е. на каждую внешнюю обработку и отчет делать свой MD?
АМ
а куда класть его? вместе с исходниками?
Z
Ну да. Обычно такие обработки если они связаны с конфой вообще в одной репе хранятся.