Как у вас в отделе принято комментировать(или вообще не принято) код, при добавлении новых объектов, отчетов там, доков и при изменении оных?

(18) Верни))

(0) Комментирую логические куски, если они большие (например, нафига циклом обхожу ТЧ). Когда на франчей работаю или фриланс - пишу еще инициалы. А при добавлении объектов где комментарий ты писать собрался? Иногда еще у отчетов в "пояснение" пишу, что отчет должен выдавать. Независимым регистрам сведений в "пояснение" пишу, где и зачем я его юзаю. Потом через месяц это все устаревает и непойми зачем продолжает висеть и вводить в заблуждение окружающих

(0) Тема комментов обсосана до дыр.

(23) покажи на мисте... тему комментов кроме этой

(0)Удобно когда после программиста остаются комментарии нафейхуа он написал этот код.

// работает плохо, но устраивает - потом переделать
// это условие не выполняется никогда
//нафига оно нужно не знаю но пусть будет

Дарю шаблоны коментов.

(22) ай молодца, вот тож так думаю
(25) ну да.., как я думаю, комменты обязательны для логических блоков, описания процедур, но не для регистрации изменений: "Алеша, поменял код в 12-00, потому что удалил пробел в сообщении"

(24) Мне заняться больше нечем? В поеск.

(28) Тут баном попахивает.., утверждаешь, а ссылки не даешь...

старемся примерно так, более запутанный код комментарий что может делать
//+ фамилия такая20140129 Проект такой, обработка операторского товара
ТекСтрока = ЭлементыФормы.Товары.ТекущаяСтрока;
Если ТекСтрока.Номенклатура = Справочники.Номенклатура.ПустаяСсылка() Тогда // исключим пустой запрос
    Возврат;
КонецЕсли;
    
Если не Найти(ТекСтрока.Номенклатура.НоменклатурнаяГруппа.Наименование, "SIM") = 0 Тогда
        ОбщегоНазначения.СообщитьОбОшибке("Товар относиться к операторскому, выбор серии невозможен. Введите серию вручную");
Возврат;
КонецЕсли;
//- фамиля такая 20140129 было

(22) >А при добавлении объектов где комментарий ты писать собрался?
В модуле объекта самое то.

> Потом через месяц это все устаревает и непойми зачем продолжает висеть и вводить в заблуждение окружающих
+100

(27) Ахаха, сегодня в одной базе обнаружили
Возврат; //что-то *уево списалось

(30) Франч?

(32) Гы.., пЕсатели)

(0)

//<----Имя.какаято хрень
...

//--------какаято хрень. конец--->

или чтото типа
//+ программер 2013/07/10 заказчик просить добавить наличные по умолчанию
//-программер 2013/07/10

30% комментариев у меня в стиле, "И зачем это всё надо..."

(35) не, это понятно, формат, тут вопрос в месте, где делается)

+(35)со снегопатом  щас всесто < и >ставлю { и }-- получается сворачиваемый регион.  Очень удобно

(36) Франч? Это актуально для франчей?

(38)В коде там где чуешь что через неделю сам тут увязнешь при разюоре. в Объектах в описании.

(41) Плюсану..., тож так же считаю

(41) А например, если надо полностью переписать запрос, например оптимизировать, поля на выходе те же, логика не менялась?

Я комментариями этапы отмечаю. Типа
//1. Собираем все в кучу
....
//2. Обрабатываем по заданному алгоритму
...
//3. Пишем результат
...

(43)ремарю его полностью и сворачиваю в регион с названием "Старый запрос". Рядом пишу новый. Это если запрос сложный. Простые просто заменяю, не особо комментируя.


//> Отдел Дата Добавлено/Изменено
//< Отдел Дата

не франч

(44) ну норм, по сути описание алгоритма, а когда меняешь что-то, какие-то пометки делаешь?

(44)Я тоже часто этапы объясняю что и как.Только циферки давно отучился ставить. Когда в середину бллок вставляешь и комментиуешь, неперенумеровывать же все:-)

(46) Для чего такие пометки, что бы на доработку отправлять?

ИМХО, комментирование как эмуляция системы контроля версий - это зло. При частых или серьезных доработках больше вреда чем пользы. На эти вопросы отвечает система контроля версий.
А комментарии нужны тогда, когда без них тяжелее код читается.

(50) прямо в 10-ку, если дохрена комментов - это офигенный минус, который растягивает код...

(50) +100 плюс еще связь коммита с системой баг-трекинга, где детально описано, кому, зачем и почему.
Да еще может быть и 5 коммитов сделано, пока задача закроется, да еще и разнесенные по времени.

Еще вопрос: Есть закоменченный код, который не работает уже долгое время, например было переписано - оптимизировано, что с ним делаете?

(47) Не всегда. Если алгоритм меняется, тогда пишу. Если ошибки, то не пишу)

(54) Фотку посмотрела?)

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

(53)Вырезать нещадно.

(0) латиницией
//+сокращенное название организации, Фамилия И.О. год и мой никнэйм =^..^=
//-сокращенное название организации

(57) 100%)

(58) Для чего делаешь так?

(55) Ну прям красавец мужчина) Можешь убирать)

(56) ну да и это правильно, в многих книжках так и учат

(58)Забыл кличку собаки, группу крови и краткий анализ кала:-)

(60) чтобы код комменитить или конкретнее что хотели спросить?

(60) Ну, это, наверное, имеет смысл при разовых небольших доработках типовых у случайного клиента на выезде.

(64) Для чего стока инфы в комментах?

(65) + Когда другой франч приедет обслуживать - спасибо скажет.

(66) что бы можно было-бы найти и в бубен дать.

(65)Ага...Доджешься от франей чтобы они подписывали свои поделки:-)

работаю фикси-фра
1)латиницей, чтобы в коде на русском языке, искать легче было
2)название организации,чтобы отличить наши ли писали или чужие :) в паре с другим программистом заставляю его комментить код в моих базах в подобном формате.
2)фио - понятно
3)год - инфа, большей части для меня когда смотришь код написанный в N-ом году, анализируешь свой скилл в текущем году :)
4) никнэйм для быстрого поиска именно своих доработок
5) забыл добавить, "описание" #заявки и краткая инфа

(70) не мешает?

(49) Дата обязательна, т.к. иногда требуется узнать когда то или иное изменение начало работать, либо наоборот, когда что-то закомментировали.
Отдел вместо фамилии для удобства поиска таких фрагментов.

(50) Если бы при коллективной разработке в 1С была интегрированная нормальная система контроля версий, от этих костылей можно было бы избавиться.

(71) не совсем понял, точнее вопрос

(74) комментарии должны обхяснять зачем этот  код работает. напимер вы перебираете таблицу и удаляете одни жлементы и изменяете другие. В комментария х необходимо объяснить в чем бизнес смысл этого перебора. И т.д.
а вообще я с проблемой слишком много комментариев не сталкивался. а вот наоборот - постоянно. Все считают, что настолько хорошо пишут код, что и комменты к нему не нужны. но поскольку 95% населения идиоты, то результат получается соответственный.

//<<<--- Описание

     Код;

//--->>>

Для удобства поиска доработок

(73)Чем тебе хранилище не угодило для этого?

(77) бранчей не хватает...

(56) а мне больше близка позиция Макконнела:
- описывать в комментарии цель блока кода - т.е. для чего код делает то что делает
- блоки кода не требующие объяснений, но объединенные одним смыслом предварить кратким комментариеем, чтобы можно было легко выделять блоки визуально и понимать их смысл не вчитываясь в код

(74) Не мешает читаемости и восприятию кода, при внесении изменений?

(75) Опять же, комменты должны нести какую-то  смысловую нагрузку, описание алгоритма, функции, процедуры, но не дату изменения и редактирования.

(80) нет
(79) Если по-русски сказать в 1С комменты нужны для сравнения с типовым кодом при обновлении.
Я не думаю что обновляющий программист будет читать описание для чего и как код работает :) ему важнее видеть какой код типовой а какой нетиповой. Простым описанием не обойтись т.к будет непонятно кто внес эти комменты разработчики 1С или программер Вася.

(82) вот, если конфа - самописка, на основании например УТ, которая не обновляется вообще

(82) почему при обновлении? есть много конфиг которые не вообще обновляются

(83)(84) это тоже не отрицаю, тем кто пишет их сами понимают что лучше комментить код, чтобы не рыть себе яму :)
и вообще придерживаться хорошего тона в программировании

(78) переходи на git.

(82) обновляй нормально и тогда будет понятно, где изменения поставщика, а где ВАси.

(85) Вот тут хороший тон (50) и (56)

(86) нормально делай нормально будет да

(88) начни с обновления конфигурации поставщика.

(89) так значит вот кто не оставляет комментарии в коде

(0)
//Префикс компании_дата_фио
//бла
//бла
//бла
//----

(90) А зачем? У меня все шаги записаны.
https://lh6.googleusercontent.com/-xjHcbDPQomw/U38lxNu41CI/AAAAAAAAA2s/mmGoZAL-4fs/w1284-h547-no/Snap47.png

(92) Хранилище?

(93) git

(33) нет, 3 поколения программистов сменилось, отчетность по проектам

(0)

//ФИО, дата внесения
//релиз конфигурации
//информация о проектном решении
//НачалоИзменения{

...........

//КонецИзменения
//ФИО

(31) В свойстве "Комментарий" же

(96) Не запаривает такие "развернутые" комменты делать?

А нахрена?(96)

(100)!
(99) чтобы следующему было понятно, нахерна эти костыли

(100) А писать НЕкостыли не?

Я почти никогда не комментарю :-(, все равно все изменения только сравнениями конфы вытаскиваются, а просто инфу, что кто-то что-то поменял в типовом отчете мне лично отродясь нужна не была...

+(102) А когда пишу что-то достаточно большое, стараюсь давать максимально внятные названия процедурам-функциям-переменным, чтобы по одним названиям было ясно что делается...

(102) Во, плюсану, ваще, по-хорошему нужно ТЗ, в котором задачи пишутсЯ и если конфа не типовая и не требующая обновлений, комменты нахрен не нужны, ну исключая алгоритмы и функции плюс имена функциям, переменным давать нормальные надо

(45) Делаю так же. Старый код закомментирую, если он важный. Неважный код просто меняю.

//+<фамилия> дата <номер задачи> - <описание изменеий одной строкой>
...
//=
в первой строке + это добавление, - удаление, ~ изменение. при изменении оставляю старый код, через какое-то время удаляю.
для семёрки был в своё время макрос для опенконфа - выделяешь кусок кода, говоришь что хочешь сделать - скопировать, удалить или вставить, и он этот кусок так комментирует. может и для снегопата есть.
номер кстати помогает - недавно позвонили с прошлой работы, что-то у них там при очередном обновлении затёрлось, сказал что номера указывал и они нашли в копии именно по номеру

(101) да вот, кстати, меня тоже вопрос мучает, зачем программисты пишут программы с ошибками? может, лучше сразу без ошибок писать? всем же будет легче

Есть мнение, что код который требует комментария не имеет право на существования. По одному взгляду на алгоритм долдны быть понятно, что он делает - если это не так то никакие комменты не спасут ибо проще удалить все и написАть заново.

Ой, как я посмотрю - все сплошь супер спецы собрались) Код пишут идеальный, в комментариях не нуждающийся. Элита прям))

(109) вроде как про идеальный код ни слова сказанно не было, код должен быть в первую очередб читабельным а уж в десятую идеальным (ибо к идеалу надо стремится всю жизнь и все равно его не достичь :) )

(110) Я вот как-то не всегда уверена в том, что человеку со стороны сразу будет понятно, что делает мой код.
Или еще вариант - допустим, при сохранении объекта совершается несколько несвязанных друг с другом действий, и я дописываю туда же еще одну хотелку от клиента, я их комментирую просто для того, чтобы потом, прочитав комментарий можно было понять, что это не то, что я ищу и не вчитываться в код после комментария.
Я не считаю зазорным комментировать свои действия. Ведь всегда есть вероятность, что кому-то они будут непонятны) Но я не волшебник, я только учусь :)

(109) А то!Мои комментарии только (С).)))).

вот поучитесь комментарии писать:
Читаю и плачу. Где он такую траву брал?

(2) +1

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

(110) имейте в виду, что не все люди такие гении реверс-инжиниринга, как вы. в программировании в общем есть такое понятие как "1С", оно отличается от всех других понятий тем, что в нем есть типовые конфигурации с очень сложными структурами, запросами по 200 страниц и, как ни странно, ошибками в коде. и если я поправил кривую строку в коде запроса, потратив полдня на ее поиск, скажите, зачем следующему человеку, если я уйду из этой организации, заново искать причину и смысл моей правки и тратить столько же времени, а то и больше? если ему достаточно увидеть комментарий и СРАЗУ понять? конечно, моя правка может быть не особо верная, и 1С со временем могут этот баг обнаружить, но ведь поиск правильного решения уже будет намного легче, так? сразу видно, как вы относитесь ко всем остальным людям, да, я их тоже ненавижу, но не настолько.

[0]

добавление функционала по сравнению с типовым

// [+] VVP - добавлен вывод колонки "Колонка" в отчет {

здесь новый код, которого не было

// [+] VVP }

мелкая правка

// [*] VVP - было A=A+B

А=А+B+1;


удаление ненужного кода

// [-] VVP - следующий код стал не нужен, потому что... {
//
//
//
//  здесь ненужный код
//
//
//
//
// [-] VVP }

(104) Конечно, если конфа полностью самописная, то камменты ставятся только смысловые, без дат, фамилий, начала и конца.

Если же типовая, то наоборот, в основном без описания, но обязательна дата, кто, начало и конец.

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

(118) Да да, именно, нетривиальные вещи обязательно комментить

// Алгоритм определения типов линий на каждом уровне дерева
    // Берется цикл по уровням начиная со второго по отношению к начальному
    // ... короче дальше словами не понять - нужно выгрузить на экран ТЗ - там видно
    Для А=НачальныйУровень+2 по МаксУровень цикл
        ИмяКолонки="Ур"+Строка(А);
        НомерКолонки = 4 + А;
        Дальше=1;
        Для каждого Строка из ТаблицаПродукции Цикл
        
             Если (Строка.Уровень=А-1) и (Строка.Последний=1) Тогда
                 Дальше=0;
             КонецЕсли;                              
             Если (Дальше=0) и (Строка.Уровень<А-1) Тогда
                 Дальше=1;
             КонецЕсли;
            Если Дальше=1 Тогда
                 Продолжить
             КонецЕсли;  
             Строка.Установить (НомерКолонки,1);
        КонецЦикла;
    КонецЦикла;

Писал в 2006 году в клюшках дерево рецептов (на основании стандартного дерева документов).
Затем код переехал в УФ практически без изменений.

Попробуйте понять что делает без комменатрия