powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Программирование [игнор отключен] [закрыт для гостей] / Как будет правильно?
72 сообщений из 72, показаны все 3 страниц
Как будет правильно?
    #36952253
TREY
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Хороший программист всегда пишет комментарии.
или
Хороший программист никогда не пишет комментарии.
...
Рейтинг: 0 / 0
Как будет правильно?
    #36952265
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
On 12.11.2010 16:49, TREY wrote:
> Хороший программист всегда пишет комментарии.
> или
> Хороший программист никогда не пишет комментарии.


Хороший программист пишет комментарии, когда это нужно.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
Как будет правильно?
    #36952807
Фотография Esofter
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Хороший программист всегда пишет комментарии, к хорошим мыслям.
...
Рейтинг: 0 / 0
Как будет правильно?
    #36952901
TREY
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Esofter,

У хорошего программиста плохих мыслей не бывает
...
Рейтинг: 0 / 0
Как будет правильно?
    #36952907
Фотография Esofter
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
TREYEsofter,

У хорошего программиста плохих мыслей не бывает

программист, который комментирует только программистов - задрот. Настоящий программист должен быть образованный во всех сферах и быть достаточно компетентным для комментирования.
...
Рейтинг: 0 / 0
Как будет правильно?
    #36952936
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
TREYХороший программист всегда пишет комментарии.
или
Хороший программист никогда не пишет комментарии.
мне нравится совет Страуструпа: вначале исходника описать почему были применены нетривиальные алгоритмы и подходы, и привести ссылки на литературу где эти подходы описываются.

также неплохо комментировать не очевидный код, но сам факт наличия такого кода говорит не в пользу "хорошести" программиста.
...
Рейтинг: 0 / 0
Как будет правильно?
    #36952949
Фотография Esofter
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ааа, так вы про комментарии в коде... Я то думал про комментарии вообще :)
...
Рейтинг: 0 / 0
Как будет правильно?
    #36952950
egorych
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ZyK_BotaNтакже неплохо комментировать не очевидный код, но сам факт наличия такого кода говорит не в пользу "хорошести" программиста.очень сложно в собственном проекте такой найти ))) для меня весь код очевиден, когда я его пишу. Вот когда через пол-года смотрю на некоторые куски и думаю "и чего я это не прокомментировал тогда?", в этом вся проблема )))
...
Рейтинг: 0 / 0
Как будет правильно?
    #36952965
Фотография Esofter
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
комментарии это еще полбеды, ненавижу когда уникумы в именах переменных ставят _, а методов __

Я бы таких девелоперов клавишами накормил
...
Рейтинг: 0 / 0
Как будет правильно?
    #36953014
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
TREYХороший программист всегда пишет комментарии.
или
Хороший программист никогда не пишет комментарии.
Правильно - хороший программист пишет хорошие комментарии. Хорошие комментарии имеют несколько признаков, главный из которых: их немного и они по делу.

ZyK_BotaNмне нравится совет Страуструпа: вначале исходника описать почему были применены нетривиальные алгоритмы и подходы, и привести ссылки на литературу где эти подходы описываются.
В начале исходника имхо стоит прежде всего кратко описать смысл этого исходника и, если не тривиально, его место в архитектуре проекта. Затем - нетривиальную информацию, которую следует иметь в виду при знакомстве с модулем, в том числе особые подходы, неочевидные ограничения, специфические варианты использования и т. п.

ZyK_BotaNтакже неплохо комментировать не очевидный код, но сам факт наличия такого кода говорит не в пользу "хорошести" программиста.
Чушь. Факт наличия говорит не в пользу "стандартности" программиста. Например, код, вполне очевидный "другому хорошему программисту", будет вовсе не очевиден "многим другим программистам".
...
Рейтинг: 0 / 0
Как будет правильно?
    #36953086
Edd.Dragon
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
EsofterХороший программист всегда пишет комментарии, к хорошим мыслям.
У хорошего программиста код тоже хороший. А это значит, что 90% его мыслей самодокументированы. Т.е. читая код, ты и понимаешь что имелось ввиду. Написание к нему коментво будет лишь повторением.

Типа (тривиальный пример):

// увеличиваем i
i++;


Т.е. правильный ответ:
MasterZiv
Хороший программист пишет комментарии, когда это нужно.


В основном только описания перед классами, методами и т.д. для последующего формирования документации и вообще для описания что чего делает. А в коде коменты могут понадобиться только лишь в редких неочевидных по смыслу блоках. Подавляющее большинство кода должно быть написано просто и понятно, легкочитаемо, что устраняет необходимость в коментах.
...
Рейтинг: 0 / 0
Как будет правильно?
    #36953088
Edd.Dragon
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
TREYEsofter,
У хорошего программиста плохих мыслей не бывает
Контрпример: "Заказчик - му***!!! >8-( "
...
Рейтинг: 0 / 0
Как будет правильно?
    #36953091
Фотография Esofter
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Edd.Dragon,

блоки саммари(приведу пример из дотнета, он мне ближе) считаю обязательными. Остальные излишние, ну разве только в специфических ситуациях, когда алгоритм просто выносит моск без обьяснений :)
...
Рейтинг: 0 / 0
Как будет правильно?
    #36953096
Edd.Dragon
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
EsofterEdd.Dragon,

блоки саммари(приведу пример из дотнета, он мне ближе) считаю обязательными. Остальные излишние, ну разве только в специфических ситуациях, когда алгоритм просто выносит моск без обьяснений :)
Ну да, я о том же ))
Тогда твое " всегда пишет" = моему " не всегда " ))))
...
Рейтинг: 0 / 0
Как будет правильно?
    #36953097
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Edd.DragonTREYEsofter,
У хорошего программиста плохих мыслей не бывает
Контрпример: "Заказчик - му***!!! >8-( "
это в комментариях нужно пояснять?
...
Рейтинг: 0 / 0
Как будет правильно?
    #36953102
Фотография Esofter
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ZyK_BotaNEdd.Dragonпропущено...

Контрпример: "Заказчик - му***!!! >8-( "
это в комментариях нужно пояснять?

обязательно. Я один раз в комментариях написал что мне стыдно за код ниже, я не придумал ничего лучше так как заказчик сцуко подгонял и ему пох красиво код написан или нет.
...
Рейтинг: 0 / 0
Как будет правильно?
    #36953670
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
On 12.11.2010 22:35, Esofter wrote:

> ааа, так вы про комментарии в коде... Я то думал про комментарии вообще :)

Да, вот кстати. Хороший программист не должен писать комментарии в ЖЖ.

Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
Как будет правильно?
    #36953802
Фотография Esofter
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZiv
On 12.11.2010 22:35, Esofter wrote:

> ааа, так вы про комментарии в коде... Я то думал про комментарии вообще :)

Да, вот кстати. Хороший программист не должен писать комментарии в ЖЖ.



вообще - это для тебя ЖЖ? Есть еще хабрахабр, ПТ на худой конец :)
...
Рейтинг: 0 / 0
Как будет правильно?
    #36956791
EsofterПТ на худой конец :)
ПЦ?

По теме топика: не комментарии украшают программиста, а программист комментарии. Поэтому правильно будет так: хороший программист сам знает, какие комменатрии писать, сколько, и в каких контекстах.
Если хочецца оценить правильность комментариев, найди свою прогу 10 летней давности и угадай, как она работает ;)
...
Рейтинг: 0 / 0
Как будет правильно?
    #36956845
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
УнрегистередЕсли хочецца оценить правильность комментариев, найди свою прогу 10 летней давности и угадай, как она работает ;)
Меня всегда удивляли люди, у которых с этим проблемы. Свою первую серьёзную программу я написал двадцать с небольшим лет назад, но хотя в ней довольно мало комментариев, я без проблем расскажу, как она работает. И поясню детали, глядя на исходник. И на самом деле, подозреваю, любой нормальный программист спокойно в ней разберётся.
...
Рейтинг: 0 / 0
Как будет правильно?
    #36956920
MasterZiv
On 12.11.2010 16:49, TREY wrote:
> Хороший программист всегда пишет комментарии.
> или
> Хороший программист никогда не пишет комментарии.


Хороший программист пишет комментарии, когда это нужно.


Т.е. практически никогда (код должен быть очевиден, и читаем сам по себе, иначе это не код, а бред).8
...
Рейтинг: 0 / 0
Как будет правильно?
    #36956942
Edd.DragonВ основном только описания перед классами, методами и т.д. для последующего формирования документации и вообще для описания что чего делает. А в коде коменты могут понадобиться только лишь в редких неочевидных по смыслу блоках. Подавляющее большинство кода должно быть написано просто и понятно, легкочитаемо, что устраняет необходимость в коментах.

Не надо нести этот бред. Концептуальные, архитектурные вопросы - они описываются в отдельных
документах. Техническое задание, Технический проект и т.д.

В коде это все описывать - не нужно. Кто это будет читать?

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

Более того, даже надписи внутри этого танка, которые для танкистов - бессмысленны.
Зачем танкисту читать надпись вида "снаряд брать правой рукой, и класть в автомат-податчик"?

Он эти надписи должен прочитать ЗАРАНЕЕ, в специальном РУКОВОДСТВЕ. А не во время боя.

Делайте выводы, дети.
...
Рейтинг: 0 / 0
Как будет правильно?
    #36956980
Фотография Esofter
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Безумный DBAEdd.DragonВ основном только описания перед классами, методами и т.д. для последующего формирования документации и вообще для описания что чего делает. А в коде коменты могут понадобиться только лишь в редких неочевидных по смыслу блоках. Подавляющее большинство кода должно быть написано просто и понятно, легкочитаемо, что устраняет необходимость в коментах.

Не надо нести этот бред. Концептуальные, архитектурные вопросы - они описываются в отдельных
документах. Техническое задание, Технический проект и т.д.

В коде это все описывать - не нужно. Кто это будет читать?

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

Более того, даже надписи внутри этого танка, которые для танкистов - бессмысленны.
Зачем танкисту читать надпись вида "снаряд брать правой рукой, и класть в автомат-податчик"?

Он эти надписи должен прочитать ЗАРАНЕЕ, в специальном РУКОВОДСТВЕ. А не во время боя.

Делайте выводы, дети.

комментарии нужны для метаданных, в них можно описать назначения методов классов, типы и назначения параметров.
Использование классов с такими метаданными очень облегчают жизнь, не нужно заводить документации по детальным описаниям объектной модели приложения.
...
Рейтинг: 0 / 0
Как будет правильно?
    #36957030
Edd.Dragon
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Безумный DBA
Зачем танкисту читать надпись вида "снаряд брать правой рукой, и класть в автомат-податчик"?

"снаряд брать правой рукой, и класть в автомат-податчик" - это не коментарий, а код функции "заложить снаряд".

Если же речь об описании функций АПИ или фреймоврка, то значит "снаряд брать правой рукой, и класть в автомат-податчик" - это описание-шапка функции, необходимое для автоматического формирования документации по классу, модулю и т.д. Это бред?

авторВедь в реальном мире ни у одного конструктора не возникает желания рисовать комментарии, ну я не
знаю, внутри башни танка, поясняя там, почему он выбрал именно данный тип сварки, толщину брони
или диаметр болтовых соединений или марку стали.
Так и я вроде таких коментариев не предлагал писать.
...
Рейтинг: 0 / 0
Как будет правильно?
    #36957060
Edd.Dragon
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Безумный DBA
Он эти надписи должен прочитать ЗАРАНЕЕ, в специальном РУКОВОДСТВЕ. А не во время боя.

И снова таки вопрос. Руководство, описыывающиее назначение системы, обоснование выбранных архитектурных решений и т.д.? Или же документация по функциям АПИ/фреймворка?
...
Рейтинг: 0 / 0
Как будет правильно?
    #36957237
Фотография AndreTM
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Народ, вы много видели документированного кода?
Вообще, чем выше класс программиста - тем меньше приходится документировать код. Ибо... и ИМХО.
...
Рейтинг: 0 / 0
Как будет правильно?
    #36957361
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Безумный DBAВедь в реальном мире ни у одного конструктора не возникает желания рисовать комментарии
В реальном мире передо мной стоит компьютер. Я вижу, помимо марок производителя, надписи на кнопках на мониторе, рисунки микрофона и наушников на гнёздах передней панели системника, подписи под лампочками на клавиатуре и кучу других полезных комментариев.
...
Рейтинг: 0 / 0
Как будет правильно?
    #36957369
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Edd.Dragonэто описание-шапка функции, необходимое для автоматического формирования документации по классу, модулю и т.д. Это бред?
Автоматическое формирование документации - это бред. Как раз одна из тех вещей, которые не относятся к комментариям по делу.
...
Рейтинг: 0 / 0
Как будет правильно?
    #36957461
Edd.Dragon
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
AndreTMНарод, вы много видели документированного кода?
Вообще, чем выше класс программиста - тем меньше приходится документировать код. Ибо... и ИМХО.
Я все же повторю вопрос.
Имеется ввиду руководство, описывающиее назначение системы, обоснование выбранных архитектурных решений и т.д.? Или же документация по функциям АПИ/фреймворка?

авторНарод, вы много видели документированного кода?
Много

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

Иначе, накой в документации тех же фреймворков и АПИ Микрософт присутсвует документация по сотням вполне интуитивно понятных функций? Уровень их команды низкий?


softwarerEdd.Dragonэто описание-шапка функции, необходимое для автоматического формирования документации по классу, модулю и т.д. Это бред?
Автоматическое формирование документации - это бред. Как раз одна из тех вещей, которые не относятся к комментариям по делу.
Т.е. описание параметров методов, по сути хелп, не нужен в коде и его надо писать исключительно отдельно от кода, беря на себя все форматирование и т.д.? А IDE потом в подсказки должна будет выводить хелп из этой внешней документации?
...
Рейтинг: 0 / 0
Как будет правильно?
    #36957472
Edd.Dragon
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Edd.Dragon
авторНарод, вы много видели документированного кода?
Много

Любой толковый фрейморвк, АПИ или просто набор заголовочных файлов к бибилиотеке не зависимо от языка.
...
Рейтинг: 0 / 0
Как будет правильно?
    #36957483
softwarerБезумный DBAВедь в реальном мире ни у одного конструктора не возникает желания рисовать комментарии
В реальном мире передо мной стоит компьютер. Я вижу, помимо марок производителя, надписи на кнопках на мониторе, рисунки микрофона и наушников на гнёздах передней панели системника, подписи под лампочками на клавиатуре и кучу других полезных комментариев.

1) это не комментарии, это условные обозначения
2) я не смотрю на кнопки на клавиатуре. Кто вообще на них смотрит?
3) самое полезное обозначение, которое я ищу глазами - это всем известный значок кнопки питания (кружок с палочкой).

А вот если бы там стоял комментарий на русском языке (включать здесь) - я бы самолично нашел бы этого дизайнера и руки ему в двери-то и поприжал.

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

И человек, который не может доходчиво описать свою мысль в коде - вряд-ли ее опишет хорошо на естественном языке.

Ценность же этих комментариев - разве для совсем начинающих, которые даже программировать еще не умеют (в принципе).
...
Рейтинг: 0 / 0
Как будет правильно?
    #36957509
Edd.Dragon
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Безумный DBA

А вот если бы там стоял комментарий на русском языке (включать здесь) - я бы самолично нашел бы этого дизайнера и руки ему в двери-то и поприжал.

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

И человек, который не может доходчиво описать свою мысль в коде - вряд-ли ее опишет хорошо на естественном языке.

Ценность же этих комментариев - разве для совсем начинающих, которые даже программировать еще не умеют (в принципе).
Елки двадцать!

Да никто из оппонентов ранее и не говорил, что тупые коментарии нужны. Где ты видишь речь о таких бесполезных коментариях типа
Код: plaintext
1.
2.
3.
4.
5.
// включаем комп
doPCPowerOn();

// ждем загрузки
waitForOSLoaded();
?
...
Рейтинг: 0 / 0
Как будет правильно?
    #36957517
Edd.DragonБезумный DBA
Он эти надписи должен прочитать ЗАРАНЕЕ, в специальном РУКОВОДСТВЕ. А не во время боя.

И снова таки вопрос. Руководство, описыывающиее назначение системы, обоснование выбранных архитектурных решений и т.д.? Или же документация по функциям АПИ/фреймворка?

Абсолютно всю документацию следует описывать в отдельных документах.
Описывать ее в коде (идея JavaDoc) примерно настолько-же идиотичная затея, как и прикладывать
к свежевыпущенному автомобилю, во всех пикантных местах (в трубах рамы, под сиденями, в коробке передач, в шиназз) - документацию (чертежи и расчеты).
Это ведь так удобно, да? Решил поремонтировать двигатель, открываешь коробку - а там чертеж уже лежит и техкарта, для изготовления нового цилиндра из отливки.

Смешно?

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

Есть сомнения? Ну так посмотрите лишний раз на документацию в MSDN, и сравните ее с тем, извиняюсь, нечитабельным нечтом, которое генерируется через javadoc даже в самой в JDK.


Если кто опять не понял, так поясним еще раз. Документация (особенно печатная, вводная - Guide), и справочники (Reference), и код (Code) - они имеют принципиально разную структуру.
Нет? Не верится? Ну тогда откройте Oracle Concepts или Oracle SQL Reference, и просто прикиньте,
КАК пришлось бы вырывать себе мозг, чтобы разнести весь текст оттуда - по .C-ным файлам.

Потом - приходите.
...
Рейтинг: 0 / 0
Как будет правильно?
    #36957590
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Безумный DBA1) это не комментарии, это условные обозначения
Это наилучшее приближение к комментариям в изначально дурной аналогии танкиста в башне. Поскольку разработчика башни (конструктора) и её сопровожденца (ремонтника) Вы подменяете пользователем (танкистом), после чего с блеском обосновываете ненужность ему документации разработчика.

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

Безумный DBAЦенность же этих комментариев - разве для совсем начинающих, которые даже программировать еще не умеют (в принципе).
Ровно как ценность условных обозначений - для совсем начинающих, которые не могут снять кожух и посмотреть, куда и как идут провода.
...
Рейтинг: 0 / 0
Как будет правильно?
    #36957600
Edd.Dragon
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Безумный DBA
Абсолютно всю документацию следует описывать в отдельных документах.
Описывать ее в коде (идея JavaDoc) примерно настолько-же идиотичная затея, как и прикладывать
к свежевыпущенному автомобилю, во всех пикантных местах (в трубах рамы, под сиденями, в коробке передач, в шиназз) - документацию (чертежи и расчеты).
Это ведь так удобно, да?
Смешно?

Вообще-то печально.

Ибо автомобиль - это экзешник, а не код. А код - это такой же ДОКУМЕНТ как и ТЗ, и чертежи, и мануалы. Только мануалы преследуют одну цель - научить, а код - другую - реализовать (точнее описать процесс реализации). Код - это документ, по которому ты автомобиль создаешь. И в этом документе наличие поясняющих бирок как раз ни разу не идиотизм. Это всего-лишь интеграция документации (в разумных размерах) и кода для более эффективного пользования им в дальнейшем.

Так что, я упорно не могу понять аналогии исходника с автомобилем. Скомпиленный дистрибутив = автомобиль.


Безумный DBA
Решил поремонтировать двигатель, открываешь коробку - а там чертеж уже лежит и техкарта, для изготовления нового цилиндра из отливки.

Смешно?

Открываешь пакет с чертежом и инструкцией по изготовлению по этому чертежу. Одно из них мануал, другое - код. Удобно, что они лежат вместе? Удобно. Это мешает иметь еще и автоматически ксерящийся по ним набор просто инструкций или просто чертежей, если такой набор понадобится? Не мешает.
...
Рейтинг: 0 / 0
Как будет правильно?
    #36957641
Edd.Dragon
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Безумный DBA
Описывать ее в коде (идея JavaDoc) примерно настолько-же идиотичная затея, как и прикладывать

Эта идея возникла еще когда Явы и в помине не было.
Идея JavaDoc состоит лишь в стандартизации таких коментариев для генерации из них симпатишной html-документации, но не в их необходимости.

авторЕсть сомнения? Ну так посмотрите лишний раз на документацию в MSDN, и сравните ее с тем, извиняюсь, нечитабельным нечтом, которое генерируется через javadoc даже в самой в JDK.
Есть сомнения.
Ибо наличие MSDN никак не устраняет необходимости иметь сокращенные описания и подсказки по функциям и их параметрам. Где-то они должны храниться. Так какой смысл их хранить в отдельных файлах, если они таки лаконичные и могут прекрасно дополнять сам код, не мешая его читать, т.к. находятся между логическими блоками, между функциями?
...
Рейтинг: 0 / 0
Как будет правильно?
    #36957647
softwarerБезумный DBA1) это не комментарии, это условные обозначения
Это наилучшее приближение к комментариям в изначально дурной аналогии танкиста в башне. Поскольку разработчика башни (конструктора) и её сопровожденца (ремонтника) Вы подменяете пользователем (танкистом), после чего с блеском обосновываете ненужность ему документации разработчика.
Ничего не понял про блеск. А вот вопрос - нужна ли документация на танк в самом танке?
Или давайте поговорим про необходимость технологической и конструкторской документации в составе ремонтной? Нужны ли ремонтнику данные о марке стали, режимах резания, эпюры прочностных расчетов?

Слабо?


softwarer
Безумный DBA(условных обозначений - ключевых слов, идентификаторов, операторов и т.д.)
Чушь. Ключевые слова, идентификаторы итп - это те кнопки, рукоятки, прицелы и прочие приспособления, которые есть в башне. И, разумеется, любой натренированный в этой модели танкист нажимает их на ощупь, ровно как программист, хорошо ориентирующийся в том или ином участке кода. А для тех, кто осваивает новую технику, придумали комментарии, позволяющие быстрее найти нужный тумблер.
Отлично. Я об этом и говорил. Все эти коментарии - описаны в отдельной книжке. Которую читают один раз, при первом знакомстве с танком. И никакой необходимости иметь их постоянно "под рукой" у танкиста - не возникает. А если же он видит в тепловизоре какие-то слова на русском языке - то увы, это не законченные предложения. А именно условные обозначения.

Вплоть до того, что вместо крестика может быть написано слово цель (потому что крестик не по центру). Но это не комментарий. Это - условное обозначение. Идентификатор.

softwarer
Безумный DBAЦенность же этих комментариев - разве для совсем начинающих, которые даже программировать еще не умеют (в принципе).
Ровно как ценность условных обозначений - для совсем начинающих, которые не могут снять кожух и посмотреть, куда и как идут провода.
Нет. Ценность условного обозначения в том, чтобы, к примеру, я, на незнакомом компьютере, пытаясь достать CD-ROM из лотка - нажал на кнопку, открывающую лоток. А не рядом расположенную кнопку выключения питания.

И не более того.

А если бы там было написано нечто идиотское вроде "Вот эта кнопка открывает лоток экстрактора привода оптических дисков DVD, CD-RW" - вот это был-бы пример типового программисткого идиотизма: писать комментарии с нулевой полезностью, но предельно отвлекающие каждый раз,
когда на них кто-то наталкивается (и благополучно игнорируемые впоследствии).


И вообще. О чем вы спорите? Идите и посмотрите сами, как вопрос комментирования решен у более
умных людей в смежных областях - строителей, механиков, даже химиков, медиков и ботаников всяких.

Потом приходите.
...
Рейтинг: 0 / 0
Как будет правильно?
    #36957653
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Edd.DragonТ.е. описание параметров методов, по сути хелп, не нужен в коде и его надо писать исключительно отдельно от кода,
В подавляющем большинстве случаев их вообще не надо писать. Смысл параметра и так ясен из имени параметра и смысла метода, максимум необходимо его упомянуть (примерно как "Метод String.ReplaceAll заменяет в строке все вхождения по маске Pattern на значение Replacement").

Хелп не нужен в коде, равно как в нём не нужны руководство пользователя, план тестирования, бюджет отдела программирования и уйма других интереснейших документов.
...
Рейтинг: 0 / 0
Как будет правильно?
    #36957663
Edd.DragonЕсть сомнения.
Ибо наличие MSDN никак не устраняет необходимости иметь сокращенные описания и подсказки по функциям и их параметрам.
А кто их читает, описания эти? Сделайте опрос в своем коллективе. Узнаете много нового о умственных способностях того, кто заставил писать их.

Edd.Dragon Где-то они должны храниться. Так какой смысл их хранить в отдельных файлах, если они таки лаконичные и могут прекрасно дополнять сам код, не мешая его читать, т.к. находятся между логическими блоками, между функциями?
Кто они? Краткие комментарии? Они вообще не нужны. Читайте код.

Не пишите фукнкции вида XDDF23prtfZ2(int a23kts, String tppkztms);

Пишите проще.

DataImportFromFormX23(int MethodID, String fileDataPartition);
...
Рейтинг: 0 / 0
Как будет правильно?
    #36957707
Edd.DragonБезумный DBA
Абсолютно всю документацию следует описывать в отдельных документах.
Описывать ее в коде (идея JavaDoc) примерно настолько-же идиотичная затея, как и прикладывать
к свежевыпущенному автомобилю, во всех пикантных местах (в трубах рамы, под сиденями, в коробке передач, в шиназз) - документацию (чертежи и расчеты).
Это ведь так удобно, да?
Смешно?

Вообще-то печально.

Ибо автомобиль - это экзешник, а не код. А код - это такой же ДОКУМЕНТ как и ТЗ, и чертежи, и мануалы.
Для меня, как архитектора, понаписанный кодером код - такой-же бессмысленный набор закорючек, как и бинарный .EXE файл. Вот честно.

Если до сих пор не понятно, поясним. Для кого пишутся эти комментарии в коде? Зачем они там?
Кто их будет там читать?

Edd.Dragon
Только мануалы преследуют одну цель - научить, а код - другую - реализовать (точнее описать процесс реализации). Код - это документ, по которому ты автомобиль создаешь. И в этом документе наличие поясняющих бирок как раз ни разу не идиотизм. Это всего-лишь интеграция документации (в разумных размерах) и кода для более эффективного пользования им в дальнейшем.
Вообще ничего не понял. А чем названия классов и переменных - не бирки?

Edd.DragonТак что, я упорно не могу понять аналогии исходника с автомобилем. Скомпиленный дистрибутив = автомобиль.
Вовсе нет. Не дистрибутив. Сам код - это уже конечный продукт. Никто уже (из людей, кроме кодеров, которые, по сути, эдакие биороботы по переработке спецификаций в строки кода) не
работает с ним. Даже тестировщики и те не смотрят на сам код. Смотрят на сами интерфейсы и спецификации.

Т.е. я, вот честно, не вижу разницы между дистрибутивом и кодом. И тот и то - конечный результат,
только формат представления чуть более человеко и чуть более машиночитаемый, соотвественно.

Edd.Dragon
Безумный DBA
Решил поремонтировать двигатель, открываешь коробку - а там чертеж уже лежит и техкарта, для изготовления нового цилиндра из отливки.

Смешно?

Открываешь пакет с чертежом и инструкцией по изготовлению по этому чертежу. Одно из них мануал, другое - код. Удобно, что они лежат вместе?
Нет, не удобно. Я уже лет пять не смотрю в справочники по API. Зачем? У меня есть исходные файлы, все интерфейсы описаны в заголовках .h. Без комментариев.

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

Edd.Dragon Удобно. Это мешает иметь еще и автоматически ксерящийся по ним набор просто инструкций или просто чертежей, если такой набор понадобится? Не мешает.

Мда. Вообще плохо, конечно, кто кодеров не учат базовым инженерным дисциплинам.
ЕСКД, ЕСТД + правилам написания пояснительных записок.

Все беды кодеров, как я понимаю, от неокрепших на простейших метафорах и аналогиях мозгов.
...
Рейтинг: 0 / 0
Как будет правильно?
    #36957748
Фотография AndreTM
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Не, ну действительно.
Давайте всё же при описании процедур и функций делать ремарку по типу BlackBox - входные параметры и результат. И ничего более не нужно .
Самому потом разбираться? - а вдруг за это время вы придумали/нашли новый алгоритм, который нафик отменит весь метод?
Разбираться другому? - в 99% новый программист (если он программер, а не кодер) может реализовать задачу сам. Зачем разбирать чужое творчество, если в голове и так уже бьётся новый подход?
Так что комментирование кода, и комментирование функционала - абсолютно разные функции. А нас заставляют делать первое, и не учат делать второе...
...
Рейтинг: 0 / 0
Как будет правильно?
    #36957752
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Безумный DBAА вот вопрос - нужна ли документация на танк в самом танке?
В танке нужна документация, облегчающая типовые задачи работы с ним. Например, на двух расположенных рядом горловинах полезны надписи, в какую из них заливать солярку, а в какую - масло. Хотя техники вроде как и без того это знают, но с надписями почему-то таки реже ошибаются.

Безумный DBAОтлично. Я об этом и говорил. Все эти коментарии - описаны в отдельной книжке.
Ага, и танкист лазает по кабине с этой книжкой, лихорадочно открывая её на нужных страницах. Интересно, Вы хоть раз видели кабину какой-нибудь мало-мальски сложной техники? Погуглите, например, фотографию кабины миг-21 и попробуйте рассказать, как пилот будет осваивать её, бегая к "отдельной книжке".

Безумный DBAsoftwarerРовно как ценность условных обозначений - для совсем начинающих, которые не могут снять кожух и посмотреть, куда и как идут провода.
Нет. Ценность условного обозначения в том, чтобы, к примеру, я, на незнакомом компьютере, пытаясь достать CD-ROM из лотка - нажал на кнопку, открывающую лоток. А не рядом расположенную кнопку выключения питания.
Да-да, именно. Вы как начинающий ищете подсказку там, где профессионал прочитает отдельную книжку и всё выяснит.

Безумный DBAИ вообще. О чем вы спорите?
Я не спорю. Я развлекаюсь, наблюдая забавные попытки выпендрёжа.
...
Рейтинг: 0 / 0
Как будет правильно?
    #36957759
AndreTMТак что комментирование кода, и комментирование функционала - абсолютно разные функции. А нас заставляют делать первое, и не учат делать второе...

Ура! Кое-кто начал кое-что подозревать.
...
Рейтинг: 0 / 0
Как будет правильно?
    #36957775
softwarerБезумный DBAА вот вопрос - нужна ли документация на танк в самом танке?
В танке нужна документация, облегчающая типовые задачи работы с ним. Например, на двух расположенных рядом горловинах полезны надписи, в какую из них заливать солярку, а в какую - масло. Хотя техники вроде как и без того это знают, но с надписями почему-то таки реже ошибаются.
Они расположены в логически понятных и очень, очень сильно разнесенных местах. И в авто - залить вместо масла бензин и наборот - нужно очень постараться и проявить недюжинные "способности" дауна.

softwarer
Безумный DBAОтлично. Я об этом и говорил. Все эти коментарии - описаны в отдельной книжке.
Ага, и танкист лазает по кабине с этой книжкой, лихорадочно открывая её на нужных страницах. Интересно, Вы хоть раз видели кабину какой-нибудь мало-мальски сложной техники? Погуглите, например, фотографию кабины миг-21 и попробуйте рассказать, как пилот будет осваивать её, бегая к "отдельной книжке".
Книжки он осваивает сидя в классе или на учебном стенде, не надо передергивать.
И я как раз говорил про то, что цитаты из книжки в кабине - ему и нафиг не нужны. Как и кодеру - комментарии к коду.

softwarerБезумный DBAпропущено...

Нет. Ценность условного обозначения в том, чтобы, к примеру, я, на незнакомом компьютере, пытаясь достать CD-ROM из лотка - нажал на кнопку, открывающую лоток. А не рядом расположенную кнопку выключения питания.
Да-да, именно. Вы как начинающий ищете подсказку там, где профессионал прочитает отдельную книжку и всё выяснит.
Садись, Саша, два.
Я и как профессионал, и как начинающий - пользуюсь метафорами. Странно, что вас там на ВМК этому не учили.

softwarerБезумный DBAИ вообще. О чем вы спорите?
Я не спорю. Я развлекаюсь, наблюдая забавные попытки выпендрёжа.
Рефлексируешь т.е.? Ну рефлексируй, рефлексируй. Оно тебе может быть даже полезно.
Наверне...
...
Рейтинг: 0 / 0
Как будет правильно?
    #36957834
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarerEdd.Dragonэто описание-шапка функции, необходимое для автоматического формирования документации по классу, модулю и т.д. Это бред?
Автоматическое формирование документации - это бред. Как раз одна из тех вещей, которые не относятся к комментариям по делу.
это точно
...
Рейтинг: 0 / 0
Как будет правильно?
    #36957846
Edd.Dragon
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Безумный DBA
Если до сих пор не понятно, поясним. Для кого пишутся эти комментарии в коде? Зачем они там?
Кто их будет там читать?

Для тех, кто пользуется этим кодом!
Что ты читаешь во всплывающих подсказках в Студии в выбадающем по Ctrl+Space списке функций? MSDN или краткие описания? Т.е. они есть, их не может не быть в нормальной среде разработки. А вопрос в том, где их хранить: в отдельной XML-ине или в исходнике. Оба варианта имеют право на жизнь. И второй вариант не является каким-то ущербным, не мешает читать код и дает необходимую, дополнительную к именам этих функций и их параметров, информацию прямо на месте, что удобно например при рефакторинге. Если кому это неудобно, так на здоровье! Но коменты то эти нужны и писать их, и править нужно. Вот только получается в отдельном файле, в котором нужно повторить объявление функции и приписать ее описание.

Убедить в том, что один вариант правильный, а другой нет - врядли получится. Кому как нравится, и у кого какая среда что поддерживает. А вот полное их отсутствие, имхо, глупо. Т.к. по большинству функций развернутое бла-бла-бла, достойное статьи в MSDN не нужно, а сами идентификаторы не всегда передают суть полноценно и к объявлению нужно добавить пару уточнений, которые и хочется видеть при выборе функций или при их правке.


Безумный DBA
Вообще ничего не понял. А чем названия классов и переменных - не бирки?

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


Безумный DBA
Вовсе нет. Не дистрибутив. Сам код - это уже конечный продукт. Никто уже (из людей, кроме кодеров, которые, по сути, эдакие биороботы по переработке спецификаций в строки кода) не
работает с ним.

Конечный продукт - это как раз то, с чем работает потребитель этого продукта. И конечный пользователь, и тестер работают (как ты и говоришь противореча сам себе), грубо говоря, с exe-шником. Пользователь им пользуется. Тестер его тестирует. При этом тестер вооружается инструкцией, спецификацией или иными доками. Но он же не доки тестирует, а продукт (exe-шник, web-сервис и т.д.).

А код - это алгоритм сборки продукта - документ, понятный производственной линии (компилятору), которая связывает указанные в алгоритме узлы указанным образом. Отличия от реального производства только в том, что продукт в целом, узлы (являющиеся более мелкими продуктами) - все виртуальное. Т.е. в реальности еще и материалы нужны, а тут не нужны. Любая деталь этого виртуального продукта в свою очередь является таким же виртуальным продуктом, только что или ранее аналогичным образом собранная компилятором.

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


Безумный DBA
Мда. Вообще плохо, конечно, кто кодеров не учат базовым инженерным дисциплинам.
ЕСКД, ЕСТД + правилам написания пояснительных записок.
Все беды кодеров, как я понимаю, от неокрепших на простейших метафорах и аналогиях мозгов.
Все беды *не знаю, кем вы себя величаете* в том, что вполне ясное название "Единая система конструкторской документации" загадочным образом трансформируется в "Единственно истинная система документации в любых (или в моих, а других не бывает) проектах". При чем пусть даже и истинная, но при этом не терпящая дополнения другими, кому-то удобными и полезными артефактами и подходами. Мол, черное, даже если вы в него нальете белого, обязано остаться черным! Как хотите! И плевать, что оно, чисто черное, тут не вовсем к месту.
...
Рейтинг: 0 / 0
Как будет правильно?
    #36957865
Edd.Dragon
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Безумный DBAAndreTMТак что комментирование кода, и комментирование функционала - абсолютно разные функции. А нас заставляют делать первое, и не учат делать второе...

Ура! Кое-кто начал кое-что подозревать.
Я начал подозревать, что мы говорим о разных вещах.
...
Рейтинг: 0 / 0
Как будет правильно?
    #36957897
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Безумный DBAОни расположены в логически понятных и очень, очень сильно разнесенных местах. И в авто -
Ну, как человек, судящий о танке по автомобилю, Вы уже сполна проявили себя "как архитектор". В следующий раз называйтесь сразу менеджером. Даю подсказку: в танке немного по-другому

Безумный DBAКнижки он осваивает сидя в классе
В первом приближении верно. После чего бежит к танку и начинает осваивать на практике. И в этом ему здорово помогают те самые "условные обозначения". Поскольку помогают перейти от теории к практике.

Впрочем, можем провести эксперимент. Я дам Вам картинку с, например, иннуитской раскладкой клавиатуры и Вы её изучите. После чего дам клавиатуру без обозначений и посмотрю, насколько успешно Вы будете набивать текст

Безумный DBAЯ и как профессионал, и как начинающий - пользуюсь метафорами.
А, ну то есть когда Вы рассказывали про рядом расположенные кнопки, Вы имели в виду вовсе не кнопки, а метафоры. Да и обобщение танка к автомобилю, видать, оттуда же. И прочие фантазии типа упорных попыток заменить содержание формой.

Безумный DBAРефлексируешь т.е.?
Ой, ты так обиделся, что даже на "ты" перешёл. Забавно.
...
Рейтинг: 0 / 0
Как будет правильно?
    #36957921
Edd.Dragon
Бред скипнут...

При чем пусть даже и истинная, но при этом не терпящая дополнения другими, кому-то удобными и полезными артефактами и подходами. Мол, черное, даже если вы в него нальете белого, обязано остаться черным! Как хотите! И плевать, что оно, чисто черное, тут не вовсем к месту.

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

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

Зулусу это все до лампочки. Его научили стрелять из лука и метать копье. Вот он и метает, как знает и как может, другого знать - и не желает, и не может, что самое смешное.

Вот так и ты. Но мне не интересны твои мироощущения от стрельбы из лука. Метай себе. Раз считаешь, что это кому-то нужно.
...
Рейтинг: 0 / 0
Как будет правильно?
    #36958023
softwarerБезумный DBAОни расположены в логически понятных и очень, очень сильно разнесенных местах. И в авто -
Ну, как человек, судящий о танке по автомобилю, Вы уже сполна проявили себя "как архитектор". В следующий раз называйтесь сразу менеджером. Даю подсказку: в танке немного по-другому
Вах! Там, наверное, вентиль! Крутишь влево - в дырку заливается масло. Крутишь вправо - в эту-же дырку льется дизтопливо?

Как интересно.

softwarerБезумный DBAКнижки он осваивает сидя в классе
В первом приближении верно. После чего бежит к танку и начинает осваивать на практике. И в этом ему здорово помогают те самые "условные обозначения". Поскольку помогают перейти от теории к практике.
Не понял я глубины мысли. Я что, где-то говорил что идентификаторы - зло и должны быть изничтожены? И кто после этого тут двигает про свои фантазии?

softwarerВпрочем, можем провести эксперимент. Я дам Вам картинку с, например, иннуитской раскладкой клавиатуры и Вы её изучите. После чего дам клавиатуру без обозначений и посмотрю, насколько успешно Вы будете набивать текст
а) зачем мне индуисткая раскладка?
б) даже в задаче индуистской раскладки - я бы с начала ее изучил до уровня слепой печати, а потом бы уже что-то начал печатать "в продуктив".
Честно говоря - да, это прикольно. Кодер, который уже пишет "солюшинз", но по ходу дела изучает документацию в коде в виде "каментсов".

Интересно то как, девки пляшут-то. Т.е. еще и не изучил проект, а уже пишет туда ерунду свою. Да.

Хотя... чему я удивляюсь, собственно?

softwarerБезумный DBAЯ и как профессионал, и как начинающий - пользуюсь метафорами.
А, ну то есть когда Вы рассказывали про рядом расположенные кнопки, Вы имели в виду вовсе не кнопки, а метафоры. Да и обобщение танка к автомобилю, видать, оттуда же. И прочие фантазии типа упорных попыток заменить содержание формой.
Метафоры - это лишь способ изучить суть объекта по аналогии с уже изученными ранее, понятными объектами.
Не более того. Тепло - оно и в Африке тепло, и в танке: природа явления термодинамики.

И никаких фантазий.
...
Рейтинг: 0 / 0
Как будет правильно?
    #36958065
Flying Dutchman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
TREYХороший программист всегда пишет комментарии.
или
Хороший программист никогда не пишет комментарии.

Как писал один из классиков программирования (к сожалению, не помню кто):


Хороший программист пишет больше комментариев, чем это кажется необходимым.


Всецело к этому присоединяюсь.
...
Рейтинг: 0 / 0
Как будет правильно?
    #36958339
Не классик
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Flying DutchmanTREYХороший программист всегда пишет комментарии.
или
Хороший программист никогда не пишет комментарии.

Как писал один из классиков программирования (к сожалению, не помню кто):


Хороший программист пишет больше комментариев, чем это кажется необходимым.


Всецело к этому присоединяюсь.

Гугл не знает таких классиков. Похоже - ты все придумал.
...
Рейтинг: 0 / 0
Как будет правильно?
    #36958382
MAPA3OT
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Безумный DBA
Не пишите фукнкции вида XDDF23prtfZ2(int a23kts, String tppkztms);

Пишите проще.

DataImportFromFormX23(int MethodID, String fileDataPartition);
Да, именно этого я и ожидал, когда открыл тему, ловите:
1) Что такое form23 - документ/источник/тип?
2) MethodID - какие методы имеются ввиду, из какого списка/справочника
3) fileDataPartition - путь абсолютный/относительный/а может это где-то в реестре/может урл?

Одна строка и 3 вопроса, теперь добавим, что дёргается эта функция из скомпилированной библиотеки - удачи в разборе кода.
...
Рейтинг: 0 / 0
Как будет правильно?
    #36958389
MAPA3OTБезумный DBA
Не пишите фукнкции вида XDDF23prtfZ2(int a23kts, String tppkztms);

Пишите проще.

DataImportFromFormX23(int MethodID, String fileDataPartition);
Да, именно этого я и ожидал, когда открыл тему, ловите:
1) Что такое form23 - документ/источник/тип?
2) MethodID - какие методы имеются ввиду, из какого списка/справочника
3) fileDataPartition - путь абсолютный/относительный/а может это где-то в реестре/может урл?

Одна строка и 3 вопроса, теперь добавим, что дёргается эта функция из скомпилированной библиотеки - удачи в разборе кода.

Извини, но ты, похоже, глуп как пень.

1) FormX23 - это форма X23 - иди ищи в вики проекта или в трекере, что это такое (спека есть на нее).
2) MethodID - ID предусматривает наличие таблице в базе данных - иди и смотри, куда смотрит лукап на экранной форме
3) fileDataPartition - это просто раздел файла. Дополнительное условие фильтра (не грузить форму целиком). Смотри на экранную форму и спеку формы X23.

Короче, МАРАЗОТ, ты что нам тут хотел сказать? Что ты суть школота и ни разу не работал с софтом?
Ну молодец, сказал. Мы тебя - поняли.

Еще есть что сказать?
...
Рейтинг: 0 / 0
Как будет правильно?
    #36958391
MAPA3OTОдна строка и 3 вопроса, теперь добавим, что дёргается эта функция из скомпилированной библиотеки - удачи в разборе кода.

Внутри одной компании (одного проекта) одна команда поставляет другой только .DLL-ку? Уди буди, на те, конфетку, иди, вон, в садике побегай, и не плачь, маленький.
...
Рейтинг: 0 / 0
Как будет правильно?
    #36958510
MAPA3OT
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Безумный DBA
1) FormX23 - это форма X23 - иди ищи в вики проекта или в трекере, что это такое (спека есть на нее).
2) MethodID - ID предусматривает наличие таблице в базе данных - иди и смотри, куда смотрит лукап на экранной форме
3) fileDataPartition - это просто раздел файла. Дополнительное условие фильтра (не грузить форму целиком). Смотри на экранную форму и спеку формы X23.Я правильно понял, что для того чтобы понять как работает одна функция, я должен последовательно

1) открыть вики проекта и там найти форму Х23 (кстати, а как я догадаюсь, что это именно форма Х23, а не сделанная кем-то автоматом экран или что-то типа того)

2) магическим образом понять, какой базе (их на проекте бывает больше одной, сюрприз, сюрприз) принадлежит MethodID (кстати, а почему база данных, ID - бывает не только в базе)

3) откуда-то узнать, про партиции в файле (кстати каком, а если их несколько какой искать в спеке?) и найти соответствующий раздел в доке?

Итого, в лучшем случае прочитать до фига всего в 3 (ТРЁХ) разных местах, а в худшем задолбать коллег (это если таковые есть, чужой проект с нуля - совсем интересная шутка), вместо того, чтобы один раз нажать ctrl+space (или что-то типа того) - быстро, удобно, чё уж там.

Безумный DBAВнутри одной компании (одного проекта) одна команда поставляет другой только .DLL-ку? А вот тут вынужден воспользоваться вашей же терминологией. У, школота, поработай в реальном мире. Ни разу не слышал слово "аутсорс"? А "библиотека предоставляется без исходных кодов"? Или ещё веселее "ну, это писалось тогда-то тем-то, а он уже уволился хз, где исходники".

Кроме ситуации один проект на всю контору с тремя программистами, в мире намного больше вариантов.
...
Рейтинг: 0 / 0
Как будет правильно?
    #36958643
Edd.Dragon
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MAPA3OTКроме ситуации один проект на всю контору с тремя программистами, в мире намного больше вариантов.
Обычно это не волнует великих гуру, которые обсуждают идеальную проектную документацию к танку с точки зрения танкиста с 30-летним опытом.
...
Рейтинг: 0 / 0
Как будет правильно?
    #36958680
MAPA3OTБезумный DBA
1) FormX23 - это форма X23 - иди ищи в вики проекта или в трекере, что это такое (спека есть на нее).
2) MethodID - ID предусматривает наличие таблице в базе данных - иди и смотри, куда смотрит лукап на экранной форме
3) fileDataPartition - это просто раздел файла. Дополнительное условие фильтра (не грузить форму целиком). Смотри на экранную форму и спеку формы X23.Я правильно понял, что для того чтобы понять как работает одна функция, я должен последовательно

1) открыть вики проекта и там найти форму Х23 (кстати, а как я догадаюсь, что это именно форма Х23, а не сделанная кем-то автоматом экран или что-то типа того)
Потому что там на английском языке так и написано, Форма X23.
А бессмысленный лепет про "сделанная кем-то автоматом экран или что-то типа того)" я и близко не понял. "Сделанная экран"? "Начальника не панимает"?

MAPA3OT
2) магическим образом понять, какой базе (их на проекте бывает больше одной, сюрприз, сюрприз) принадлежит MethodID (кстати, а почему база данных, ID - бывает не только в базе)
Во-первых - база всегда одна. Если их две-три, то основная все равно одна, остальные лишь средства импорта-экспорта и репликаций, не надо выдумывать.
Два - ID бывают только в базе, не надо сочинять ерунду.
Какой таблице принадлежит я уже сказал - если ты ВООБЩЕ НЕ ЗНАЕШЬ - идешь на экранную форму
и смотришь, куда ссылается.

Это и есть принцип самодокументации кода - т.е. документация лежит в том месте, где ты ее больше
всего ожидаешь.

Еще раз, дети, если туго доходит. Если мне вдруг стукнет в голову поменять имя таблицы с этим method_id - я пойду поменяю те места, где, по моему мнению, это нужно (т.е. на экранных формах).
И я как-то не собираюсь править нефункциональные комментарии в коде (что за бред) во всех
остальных 3024-х местах, где на нее, на эту таблицу, идет ссылка. Зачем мне это делать?
Просто потому что какой-то пряник не может проследить в коде, на какую таблицу ссылка идет?

Да что за детский лепет?

MAPA3OT
3) откуда-то узнать, про партиции в файле (кстати каком, а если их несколько какой искать в спеке?) и найти соответствующий раздел в доке?
Из вики или спецификации формы X23. На кой хрен мне документацию/спецификацию этой формы
переносить как коментарий в код? А если надо будет поправить документацию на эту форму - я что
должен буду еще и все каментсы кодеров ВЫЧИТЫВАТЬ и править? Да щаз! Делать больше нечего.

Ссылку на название формы дали? Все, кодер, свободен! Каментсы свои оставь себе.

MAPA3OT
Итого, в лучшем случае прочитать до фига всего в 3 (ТРЁХ) разных местах, а в худшем задолбать коллег (это если таковые есть, чужой проект с нуля - совсем интересная шутка), вместо того, чтобы один раз нажать ctrl+space (или что-то типа того) - быстро, удобно, чё уж там.
Афигеть!

Если тебе нужно прочитать про то, как сделать вообще, чисто просто в теории SELECT из базы данных и выложить это на экран - тебе придется почитать многое примерно так в 15-ти местах.
В документации на сервер баз данных, в основы SQL, про SQL API на клиенте, про компоненты экранных форм, про биндиндинг, и еще кучу мест.

Этож просто пипец какой-то, да? Надо чтоб было удобно, лежало в одном месте, нажал Ctrl+Space, и тебе там ВСЕ! СРАЗУ!

Ржач.

MAPA3OT
Безумный DBAВнутри одной компании (одного проекта) одна команда поставляет другой только .DLL-ку? А вот тут вынужден воспользоваться вашей же терминологией. У, школота, поработай в реальном мире. Ни разу не слышал слово "аутсорс"? А "библиотека предоставляется без исходных кодов"? Или ещё веселее "ну, это писалось тогда-то тем-то, а он уже уволился хз, где исходники".
Извини, глупыш. Но даже аутсорсеры (абсолютно все) результаты своего труда предоставляют в
исходных текстах. Существует очень мало компаний, которые предоставляют что-то в закрытых
кодах, и, как правило, это гиганты индустрии вроде Oracle или Microsoft, которым, в общем-то,
и не нужно предоставлять исходники своих продуктов (во избежание нервных срывов у покупателей).

В остальных случаях - вы сами идиоты, что работаете с библиотеками каких-то левых перцев,
которые могут ВНЕЗАПНО аннигилироваться с планеты Земля, оставив всех своих осчастливленных
клиентов вообще без вариантов дальнейшего развития (исходных кодов). Те, кто работал с Delphi
это знают очень даже не понаслышке (при переходе на новые версии среды разработки).

Короче, иди, иди, мальчик, рассказывай кому другому про .DLL-ки от аутсорсеров.


Ну или комментариев попиши, в своем чудесном коде, который никто, кроме тебя, вообще никогда и читать не будет.
...
Рейтинг: 0 / 0
Как будет правильно?
    #36959289
MAPA3OT
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Безумный DBAПотому что там на английском языке так и написано, Форма X23Ещё раз, что такое форма 23? Экранная форма, форма документной отчётность, название экранной формы? Как это понять из кода? Пройти по ссылкам? Я правильно понял перекопать все исходники?Безумный DBAВо-первых - база всегда одна. Если их две-три, то основная все равно однаОй, как всё плохо, одна основная база может быть только если прога специфическая, а так, чтоб тебе такое привести из простых примеров... Программа обрабатывает СМИ, а именно характеристику текста, определяет о ком и как написали, кроме того, для объектов берётся дополнительная инфа + много-много статистики - это одна база? А глазки в кучку не полезут если это в одну вынести? А база не треснет от таких одновременных нагрузок?Безумный DBAID бывают только в базе, не надо сочинять ерунду.М-м-м, погугли про кэширование, например, а ещё бывают разные хеши на клиентах/сервере, а ещё чего только не бывает.Безумный DBAКакой таблице принадлежит я уже сказал - если ты ВООБЩЕ НЕ ЗНАЕШЬ - идешь на экранную форму и смотришь, куда ссылается. Название таблицы можно узнать с экранной формы? Ушёл плакать. Оказывается идеология - "пользователь не должен знать что творится в базе", в корне неверна.Безумный DBAЕсли мне вдруг стукнет в голову поменять имя таблицы с этим method_idТвою-мою-их-нашу-вашу, вот так взять и поменять именования таблиц, дяденька, а у вас реальный опыт работы есть? Безумный DBA во всех остальных 3024-х местах, где на нее, на эту таблицу, идет ссылка. ссылка на одну таблицу идёт из многих мест? Убил. Как разбирать такой код - я хз.Безумный DBAЕсли тебе нужно прочитать про то, как сделать вообще, чисто просто в теории SELECT из базы данных и выложить это на экран - тебе придется почитать многое примерно так в 15-ти местах. М-м-м, создать БД, наполнить, выбрать информацию и отобразить её - это 4 (на самом деле больше, так как между выбрать и отобразить есть ещё "обработать") разных малосвязанных между собой функции, так на всякий.

То есть работать с закрытыми библиотеками (которые опять-таки не только dll) в приципе не надо, а если и работать то только с теми, которые на 100% описаны (а такие кстати есть в этом бренном мире). Странный у Вас опыт, хотя я в его наличии всё больше и больше сомневаюсь.
...
Рейтинг: 0 / 0
Как будет правильно?
    #36959349
TREY
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MAPA3OT, Безумный DBA
от части и вы и вы правы. Понятно что документировать явный код смысла нет, если человек не может разобраться с явным, то явно ему не место работать над проектом. Но вот вопрос стоит ли сложные обработки описывать? Иногда приходится сильно извращаться, что бы получить то или иное, как бы нам этого не хотелось. Стоит ли здесь писать комменты, почему именно так а не иначе? Именно в таких сложных процедурах обработки проще ответить "потому что гладиолус", чем описать как оно работает, и объяснить на пальцах. В таких случаях очень много продуктивного времени уйдет только на описание того что для тебя итак явное. и в принципе если человек даже за большее время не сможет разобраться (если ему надо то он просто обязан это сделать) в твоем коде, ему будет проще его переписать, чем выслушать тебя и понять почему именно так, и что там вообще. Ведь идея любого программиста зреет в голове много времени, и для того что бы ее понять сам мозг программиста тратит много времени на реализацию (это я о сложном).

Я например придерживаюсь того что комменты нужно писать только в проблемных местах для подальшего их устранения (например //непонятно почему на таком то месте раз в неделю такая то //ошибка, будет время посмотреть что за х-ня, время, дата).
А по поводу читабельного кода это уже культура программиста. И если другой программист толковый он или разберется(должен) или просто перепишет, так как на глубокую документацию уйдет половина байт кода самой процедуры или компоненты (за что в принципе не платят, и уже не тебе заплатят, когда что то нужно будет поправить ).
...
Рейтинг: 0 / 0
Как будет правильно?
    #36959457
MAPA3OT
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
TREY, соглашусь документировать всегда и везде - может и полезно, но, не эффективно, т.к. в большинстве случаев не пригодится.
Но в ряде случаев типа "DataImportFromFormX23(int MethodID, String fileDataPartition);" На анализы изойдёшь, пока поймёшь как оно работает, особенно, если код закрытый (я не говорю, что это невозможно, но долго).

А про такие все из себя сложные функции, позволю себе процитировать «Если вы ученый, и не можете в двух словах объяснить пятилетнему ребёнку, чем вы занимаетесь, — вы шарлатан». (Курт Воннегут). То бишь если функции настолько сложны, скорее всего, их можно и даже нужно переписать.
...
Рейтинг: 0 / 0
Как будет правильно?
    #36959732
TREY
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MAPA3OT«Если вы ученый, и не можете в двух словах объяснить пятилетнему ребёнку, чем вы занимаетесь, — вы шарлатан». (Курт Воннегут). То бишь если функции настолько сложны, скорее всего, их можно и даже нужно переписать.
У меня немного иное мнение, и Курт не является для меня авторитетом. Сложность работы функций и процедур сделаны для минимализации кода. И в середине они все перемешаны рекурсивно. Да! Можно написать просто. Но кода будет в 30-50 раз больше, но он будет не амортизирован, и нигде не применим.
А по поводу "объяснить пятилетнему ребёнку" я сомневаюсь что Перельман, доказавший гипотезу Пуанкаре сможет объяснить вам (уже не пятилетнему) что у него творится в 7 этажных формулах и 12 мерных пространствах, но дядя получил "Премию тысячелетия".
Если мозгов мало, то про что говорить с такими "программистами", которым нужно все в рот положить, потом показать, написать мануал по коду и используемых переменных, а напоследок еще и сделать за него, потому что он что то забыл?
...
Рейтинг: 0 / 0
Как будет правильно?
    #36959766
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
TREYЯ например придерживаюсь того что комменты нужно писать только в проблемных местах для подальшего их устранения (например //непонятно почему на таком то месте раз в неделю такая то //ошибка, будет время посмотреть что за х-ня, время, дата).
Этому комментарию место в багтрекере и уж точно не в исходниках. Типичный мусор, равно как //исправил_Дима, //баг_12345, //а здесь_сто_строк_старого_кода_закомментировали_на_всякий_случай итп.
...
Рейтинг: 0 / 0
Как будет правильно?
    #36959794
TREY
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarerTREYЯ например придерживаюсь того что комменты нужно писать только в проблемных местах для подальшего их устранения (например //непонятно почему на таком то месте раз в неделю такая то //ошибка, будет время посмотреть что за х-ня, время, дата).
Этому комментарию место в багтрекере и уж точно не в исходниках. Типичный мусор, равно как //исправил_Дима, //баг_12345, //а здесь_сто_строк_старого_кода_закомментировали_на_всякий_случай итп.
все правильно! И после отслеживания всех багов таких записей почти не остается (но иногда действительно бывает что отследить баг почти невозможно (ошибки в драйверах, девайсах, сторонних компонентах))
...
Рейтинг: 0 / 0
Как будет правильно?
    #36959808
MAPA3OT
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
TREYУ меня немного иное мнение, и Курт не является для меня авторитетом. Сложность работы функций и процедур сделаны для минимализации кода. И в середине они все перемешаны рекурсивно. Да! Можно написать просто. Но кода будет в 30-50 раз больше, но он будет не амортизирован, и нигде не применим. Точно? А если подумать? А если ещё раз подумать? А если попросить ещё кого-нибудь подумать? Всё, лучше точно нельзя? Ну, ладно, тогда оставляем.
Мне, кажется, что думать при написании надо так или примерно так. Надо оставаться максимально простым, и если платят зачастую за скорость, то для себя, лично мне, приятнее, когда мой код чужой человек будет читать, не призывая всемогущих демонов на мою тушку.

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

P.S. всячески советую, "Вы должно быть шутите мистер Фенман", заставила сильно задуматься и многое пересмотреть.
...
Рейтинг: 0 / 0
Как будет правильно?
    #36959837
TREY
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MAPA3OT,
у каждого по этому поводу личное мнение, и доказывать что нужно делать так, потому что я так делаю человеку, у которого стереотипы давно уже сложились бессмысленно. Здесь поможет только статистика, за кем большинство, тот и прав :) .
...
Рейтинг: 0 / 0
Как будет правильно?
    #36959853
TREY
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MAPA3OT,
а если вообще, чем более сложен код - тем он простее. Представьте что бы было ели бы у языков программирования не было возможности создавать функцию, процедуру, класс, метод, компонент. Сколько бы нужно было копипастом заниматься для написания даже самой простой программы?
...
Рейтинг: 0 / 0
Как будет правильно?
    #36960176
MAPA3OT
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
TREY, про то, что в конце концов, это личное половое дело каждого - согласен. Я именно по этому и стараюсь как можно чаще использовать выражения "как мне кажется" и "по моему мнению".

А про не было бы функций и т.д., - так это же как раз способ упрощения. Собственно ради этого каждый метод дробят на 100500 подфункций, казалось бы увеличиваем кол-во кода, а он, собака, не только не растёт, но и уменьшаясь становится понятным :)
...
Рейтинг: 0 / 0
Как будет правильно?
    #36960406
MAPA3OTБезумный DBAПотому что там на английском языке так и написано, Форма X23Ещё раз, что такое форма 23? Экранная форма, форма документной отчётность, название экранной формы? Как это понять из кода? Пройти по ссылкам? Я правильно понял перекопать все исходники?
Специально для детсадовцев повторю в третий раз.
Искать нужно не в исходниках. А в wiki и в трекере.

Нет? Опять не дошло? Повторим еще раз. Искать спецификацию на форму X23 нужно в тех документах, которые инициировали ее разработку. А не в исходных кодах.
Потом смотреть задачи, которые выполняли по ней программисты, потом смотреть в cvs/svn,
что именно они по этой задаче накомиттили.

Нет? Все равно не доходит?


Остальные твои глупости мне комментировать как-то даже лень уже.

Расти малыш. И научись думать головой, прежде чем что-то пишешь (без надежды на исполнение).
...
Рейтинг: 0 / 0
Как будет правильно?
    #36960530
MAPA3OT
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Безумный DBAИскать нужно не в исходниках. А в wiki и в трекере.

Нет? Опять не дошло? Повторим еще раз. Искать спецификацию на форму X23 нужно в тех документах, которые инициировали ее разработку. А не в исходных кодах.
Потом смотреть задачи, которые выполняли по ней программисты, потом смотреть в cvs/svn,
что именно они по этой задаче накомиттили.
Не-а, не доходит, дедушка, я могу снова и снова повторять одни и те же вопросы:
1) Как зовут того бесконечно доброго домового, который расскажет, что X23 - экранная форма, а не форма отчёта или что-то иное (если открыть словарик, то можно увидеть, что слово "форма" имеет чуть больше одного значения)?
2) В какое место засунули руки тому дереву, которое так назвало экранную форму?
3) Сколько часов займёт чтение документации + обзор всех веток в cvs/svn (сюрприз-сюрприз, там можно делать бранчи, которые, чёрт возьми, многие таки делают) + чтение всех комментов в svn (а по итогу всё тот же разбор кодов, которые "они по этой задаче накомиттили") * кол-во столь же прозрачноназванных функций * кол-во сотрудников? И нельзя ли это время потратить с большей пользой?

Конечно, можно было бы, перейдя на личности и другие вопросы продублировать, но зачем...
...
Рейтинг: 0 / 0
Как будет правильно?
    #36960571
MAPA3OTпродублировать, но зачем...

Действительно, зачем ты мне упорно пытаешься показать, что у тебя голова, а не горшочек с манной кашей?

Говоря проще - хочешь оставаться дураком, оставайся, мне то что с того? Мне уже не интересно с тобой
спорить. Просто потому что даже спорить с тобой - и то не получается. С таким же успехом можно вон
с деревом общаться.

Я серьезно. Результат - 1 в 1. Нулевой. Даже для дуба. Во дворе.
...
Рейтинг: 0 / 0
Как будет правильно?
    #36978326
Uridian
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
softwarerНапример, на двух расположенных рядом горловинах полезны надписи, в какую из них заливать солярку, а в какую - масло.


Угу. Аналогично комментарии полезны для двух процедур, имеющих абсолютно одинаковый интерфейс, и выполняющих существенно разные функции. :)

Самое трудное в работе программиста - придумывать названия переменным
...
Рейтинг: 0 / 0
72 сообщений из 72, показаны все 3 страниц
Форумы / Программирование [игнор отключен] [закрыт для гостей] / Как будет правильно?
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]