Doxygen, JavaDoc со товарищи...
От: c-smile Канада http://terrainformatica.com
Дата: 25.09.05 17:38
Оценка: 1 (1) +3 -2
Вот подумалось:

Мне кажется что концепт генераторов документации по исходному коду не работает.
Вообще. Ни разу мне не удалось воспользоваться "сгенеряченной" информацией .

Более того: В исходниках с коментариями под Doxygen тоже информацию
потреблять сложно — нужно делать мозговой парсинг каждый раз.

Вопрос — я один такой?
Если нет то давайте обсудим как жить дальше.
Что есть такое полезная документация к коду, компоненту и т.д?
Re: Doxygen, JavaDoc со товарищи...
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 25.09.05 17:59
Оценка: +1
Здравствуйте, c-smile, Вы писали:

CS>Мне кажется что концепт генераторов документации по исходному коду не работает.

CS>Вообще. Ни разу мне не удалось воспользоваться "сгенеряченной" информацией .

Не, меня твои выводы в очередной раз порадовали. Раз у тебя не вышло, значит вобще не работает. А ничего, что референс и по джаве и по .NET (и по львиной доле известных мне коммерческих библиотек для .NET) генерится автоматически?
... << RSDN@Home 1.2.0 alpha rev. 615 on Windows XP 5.1.2600.131072>>
AVK Blog
Re: Doxygen, JavaDoc со товарищи...
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 25.09.05 18:28
Оценка: 18 (1) +3
CS>Мне кажется что концепт генераторов документации по исходному коду не работает.
CS>Вообще. Ни разу мне не удалось воспользоваться "сгенеряченной" информацией .

не знаю, как по C++, но генерируемой документацией по C#-классам довольно удобно пользоваться.
Re[2]: Doxygen, JavaDoc со товарищи...
От: c-smile Канада http://terrainformatica.com
Дата: 25.09.05 18:46
Оценка: +1
Здравствуйте, DarkGray, Вы писали:


CS>>Мне кажется что концепт генераторов документации по исходному коду не работает.

CS>>Вообще. Ни разу мне не удалось воспользоваться "сгенеряченной" информацией .

DG>не знаю, как по C++, но генерируемой документацией по C#-классам довольно удобно пользоваться.


Ок. спасибо. Т.е. все-таки существуют системы в которых doxygen стиль документации работает.
Вопрос: чем обусловлен успех в данном случае? Лучшей поддержкой среды?

Гипотеза (личная, sic!): в С# и Java нет деления на .h и .cpp файлы — т.е.
просто нет места где можно собрать документацию компактно. Поэтому
сгененренный аннотированный список методов атрибутов — это собственно и
есть .h файл — место где можно увидеть картину в целом и в компактном виде.
Поправьте меня если я не прав.

Еще раз для тех кто в танке — все вышеизложенное есть мое личное мнение.
Re[3]: Doxygen, JavaDoc со товарищи...
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 25.09.05 21:07
Оценка:
CS>Гипотеза (личная, sic!): в С# и Java нет деления на .h и .cpp файлы — т.е.
CS>просто нет места где можно собрать документацию компактно. Поэтому
CS>сгененренный аннотированный список методов атрибутов — это собственно и
CS>есть .h файл — место где можно увидеть картину в целом и в компактном виде.
CS>Поправьте меня если я не прав.

Сгенерированная документация — обычно удобнее, чем h-ник, т.к. более структурирована.
Re: Doxygen, JavaDoc со товарищи...
От: GlebZ Россия  
Дата: 25.09.05 21:15
Оценка:
Здравствуйте, c-smile, Вы писали:

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

Остается "Doxygen, JavaDoc со товарищи..."


С уважением, Gleb.
Re[3]: Doxygen, JavaDoc со товарищи...
От: GlebZ Россия  
Дата: 25.09.05 21:24
Оценка:
Здравствуйте, c-smile, Вы писали:

CS>Здравствуйте, DarkGray, Вы писали:



CS>Гипотеза (личная, sic!): в С# и Java нет деления на .h и .cpp файлы — т.е.

CS>просто нет места где можно собрать документацию компактно. Поэтому
CS>сгененренный аннотированный список методов атрибутов — это собственно и
CS>есть .h файл — место где можно увидеть картину в целом и в компактном виде.
CS>Поправьте меня если я не прав.
Ты пользуешься inline?
У меня просто существует достаточно много хедренных файлов, которых компактными назвать сложно.

С уважением, Gleb.
Re[4]: Doxygen, JavaDoc со товарищи...
От: c-smile Канада http://terrainformatica.com
Дата: 25.09.05 21:37
Оценка:
Здравствуйте, GlebZ, Вы писали:

CS>>Гипотеза (личная, sic!): в С# и Java нет деления на .h и .cpp файлы — т.е.

CS>>просто нет места где можно собрать документацию компактно. Поэтому
CS>>сгененренный аннотированный список методов атрибутов — это собственно и
CS>>есть .h файл — место где можно увидеть картину в целом и в компактном виде.
CS>>Поправьте меня если я не прав.
GZ>Ты пользуешься inline?

Да и много.

GZ>У меня просто существует достаточно много хедренных файлов, которых компактными назвать сложно.


А какие проблемы?

// does something...
// returns: true if did something

inline bool something();


Где-нибудь еще:

// something implementation...

inline bool something() { return false; }
Re[2]: Doxygen, JavaDoc со товарищи...
От: c-smile Канада http://terrainformatica.com
Дата: 25.09.05 21:42
Оценка: +1
Здравствуйте, GlebZ, Вы писали:

GZ>Здравствуйте, c-smile, Вы писали:


GZ>UML для документирование быстро устаревает, и рассинхронизируется с кодом.

GZ>Код, достаточно сложен чтобы о нем говорить как о единственном справочнике. Нужно еще и по русски(английски) некоторую информацию писать.

А почему тогда не в отдельном струтризированном документе например HTML?

Просто микс фактически трех языков программирования в одном файле
это имхо слишком (C++, macro, HTML/DoxyGenMarkup)

GZ>Остается "Doxygen, JavaDoc со товарищи..."


Doxygen — для себя или для того чтобы сказать "документация? а як же!!!" ?
Вот в чем вопрос. Глеб можешь привести пример C++ библиотеки у которой хорошая DoxyGen
документация. Может я ошибаюсь и есть шастя...
Re: Doxygen, JavaDoc со товарищи...
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 25.09.05 22:27
Оценка: 6 (1)
Здравствуйте, c-smile, Вы писали:

CS>Мне кажется что концепт генераторов документации по исходному коду не работает.

CS>Вообще. Ни разу мне не удалось воспользоваться "сгенеряченной" информацией .

Работают, работают. Причем именно в doxygen и в C++. Постоянно пользуюсь как сгенерированной по собственным исходникам документацией, так и документацией по библиотеке ACE. А раньше пользовался таковой по Crypto++ и по Qt (там, правда, не Doxygen, но Doxygen от Qt-шного стиля многое взял). Кстати, проект KDE как раз успешно Doxygen-ом пользуется.

CS>Более того: В исходниках с коментариями под Doxygen тоже информацию

CS>потреблять сложно — нужно делать мозговой парсинг каждый раз.

Не сталкивался. Наверное сила привычки и знакомство с LaTeX-ом -- очень похоже получается. Да и у меня в ViM-е doxygen-овские теги раскрашиваеются, поэтому они сразу из общего текста комментария выделяются.
... << RSDN@Home 1.1.4 stable rev. 510>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re: Doxygen, JavaDoc со товарищи...
От: Epsilon Россия  
Дата: 26.09.05 02:30
Оценка:
Здравствуйте, c-smile, Вы писали:

CS>Вопрос — я один такой?

CS>Если нет то давайте обсудим как жить дальше.
CS>Что есть такое полезная документация к коду, компоненту и т.д?

Лично мне под VC 6.0 очень помогает Visual Assist X.
При просмотре кода, если не помнишь, что значит та или иная переменная, наводишь на неё указателем мыши, VA высвечивает подсказку, в которой обознаяается тип переменной, как она была инициализирована и комментарий к ней (если ты его написал предварительно).

При этом не надо отрываться от просмотра кода куда-то ещё.
Хотя при описании сложных систем этот метод, наверное, никуда не годится...
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Fornit some Fornus
Re[2]: Doxygen, JavaDoc со товарищи...
От: Павел Кузнецов  
Дата: 26.09.05 03:20
Оценка: +4
Epsilon,

> При просмотре кода, если не помнишь, что значит та или иная переменная, наводишь на неё указателем мыши, VA высвечивает подсказку, в которой обознаяается тип переменной, как она была инициализирована и комментарий к ней (если ты его написал предварительно).

> <...>
> Хотя при описании сложных систем этот метод, наверное, никуда не годится...

Имхо, в этом и есть проблема Doxygen, JavaDoc и т.п. Они приводят к документации как раз примерно такого уровня. Для описания архитектуры и т.п. почти бесполезны.
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[2]: Doxygen, JavaDoc со товарищи...
От: A.Lokotkov Россия http://www.linkedin.com/pub/alexander-lokotkov/a/701/625
Дата: 26.09.05 04:12
Оценка: +2 -1
Здравствуйте, AndrewVK, Вы писали:

AVK>Не, меня твои выводы в очередной раз порадовали. Раз у тебя не вышло, значит вобще не работает. А ничего, что референс и по джаве и по .NET (и по львиной доле известных мне коммерческих библиотек для .NET) генерится автоматически?


На этапе освоения языка (речь о java) или какой-то конкретной библиотеки, я думаю, мало кто пользуется референсом, -- информации мало и она не о том, о чем нужно. Приходится брать туторы и примеры кода (в том числе из туторов). Когда же язык или библиотека более или менее освоен, требуется знать точно, что происходит в том или ином методе некоторого класса. В результате референс опять не нужен, -- достаточно посмотреть исходный текст класса.
bloß it hudla
Re: Doxygen, JavaDoc со товарищи...
От: Conr Россия  
Дата: 26.09.05 05:02
Оценка:
Здравствуйте, c-smile, Вы писали:

Я за собой замечал следующее — если библиотека абсолютно незнакомая, то вначале такая сгенеренная документация просматривается по диагонали, чтобы просто приблизительно ознакомиться со структурой, классами, и тд. А если это уже не первый взгляд, то в случае возникновения каких-нибудь вопросов просто сразу лезу в исходный код — мне так удобнее.
Re: Doxygen, JavaDoc со товарищи...
От: magen Россия https://ru.linkedin.com/pub/alexey-smorkalov/4/283/8b8
Дата: 26.09.05 06:43
Оценка: +1
Для генерации Reference такие вещи ну просто лучше не придумаешь.

Другое дело что в документации должны быть и другие разделы:
Getting Started, HowTo, Installation....
Re[3]: Doxygen, JavaDoc со товарищи...
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 26.09.05 08:13
Оценка: +3
Здравствуйте, A.Lokotkov, Вы писали:

AL>На этапе освоения языка (речь о java) или какой-то конкретной библиотеки, я думаю, мало кто пользуется референсом,


Ну значит я не такой как все. Я пользуюсь.

AL>В результате референс опять не нужен, -- достаточно посмотреть исходный текст класса.


А я вот, уже 4 года программируя под .NET, референсом все равно пользуюсь регулярно.
... << RSDN@Home 1.2.0 alpha rev. 617>>
AVK Blog
Re[5]: Doxygen, JavaDoc со товарищи...
От: GlebZ Россия  
Дата: 26.09.05 08:17
Оценка:
Здравствуйте, c-smile, Вы писали:

Так писать мне ляниво Все в хедере.

С уважением, Gleb.
Re[3]: Doxygen, JavaDoc со товарищи...
От: GlebZ Россия  
Дата: 26.09.05 08:21
Оценка:
Здравствуйте, c-smile, Вы писали:

GZ>>UML для документирование быстро устаревает, и рассинхронизируется с кодом.

CS>А почему тогда не в отдельном струтризированном документе например HTML?
Тот же недостаток, что и с UML. Рассинхронизация действительности с описаным.

CS>Doxygen — для себя или для того чтобы сказать "документация? а як же!!!" ?

CS>Вот в чем вопрос. Глеб можешь привести пример C++ библиотеки у которой хорошая DoxyGen
CS>документация. Может я ошибаюсь и есть шастя...
Может и я ошибаюсь. C++ программы у меня не документированы.Так сложилось, что единственным пользователем являюсь я. Поэтому, опыта с данным продуктом нет. А вот на шарповский код — генерю документацию доступную многим.

С уважением, Gleb.
Re[4]: Doxygen, JavaDoc со товарищи...
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 26.09.05 08:24
Оценка:
Здравствуйте, DarkGray, Вы писали:

DG>Сгенерированная документация — обычно удобнее, чем h-ник, т.к. более структурирована.


И по ней есть поиск и индекс, что тоже немаловажно.
... << RSDN@Home 1.2.0 alpha rev. 617>>
AVK Blog
Re[3]: Doxygen, JavaDoc со товарищи...
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 26.09.05 08:24
Оценка:
Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Имхо, в этом и есть проблема Doxygen, JavaDoc и т.п. Они приводят к документации как раз примерно такого уровня. Для описания архитектуры и т.п. почти бесполезны.


Ну, в NDoc кое какие возможности есть + легко прикрутить свои собственные.
... << RSDN@Home 1.2.0 alpha rev. 617>>
AVK Blog
Re: Doxygen, JavaDoc со товарищи...
От: anonymous Россия http://denis.ibaev.name/
Дата: 26.09.05 09:05
Оценка:
Здравствуйте, c-smile, Вы писали:

CS>Вопрос — я один такой?

CS>Если нет то давайте обсудим как жить дальше.
CS>Что есть такое полезная документация к коду, компоненту и т.д?

POD?...
Re[4]: Doxygen, JavaDoc со товарищи...
От: Павел Кузнецов  
Дата: 26.09.05 12:55
Оценка:
AndrewVK,

> ПК>Имхо, в этом и есть проблема Doxygen, JavaDoc и т.п. Они приводят к документации как раз примерно такого уровня. Для описания архитектуры и т.п. почти бесполезны.


> Ну, в NDoc кое какие возможности есть + легко прикрутить свои собственные.


А смысл? Имхо, за исключением ссылок на справочную информацию по конкретным компонентам, привязка к Doxygen/JavaDoc/NDoc в плане документирования архитектуры/установки/rationale и т.п. ничего по сравнению с описанием отдельно не дает, только накладывает свои ограничения, которые приходится доблестно преодолевать.
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[5]: Doxygen, JavaDoc со товарищи...
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 26.09.05 13:22
Оценка: +1
Здравствуйте, Павел Кузнецов, Вы писали:

ПК>А смысл?


Меньше кнопок жать. Плюс NDoc содержит компилятор chm, не нужно дополнительной тулзы. Плюс единый стиль оформления.

ПК> Имхо, за исключением ссылок на справочную информацию по конкретным компонентам, привязка к Doxygen/JavaDoc/NDoc в плане документирования архитектуры/установки/rationale и т.п. ничего по сравнению с описанием отдельно не дает, только накладывает свои ограничения, которые приходится доблестно преодолевать.


Ну вобщем да. Правда и ограничений особых тоже нет. NDoc не особо хуже любого другого компайлера chm.
... << RSDN@Home 1.2.0 alpha rev. 617>>
AVK Blog
Re[3]: Doxygen, JavaDoc со товарищи...
От: vladserge Россия  
Дата: 26.09.05 14:49
Оценка: +1
Здравствуйте, c-smile, Вы писали:


CS>Просто микс фактически трех языков программирования в одном файле

CS>это имхо слишком (C++, macro, HTML/DoxyGenMarkup)

Есть такое ощущение, что это явление временное.
Когда руки дойдут, появятся нормальные редакторы кода которые вместо HTML-ных кракозябр будут выдавать нормальный Rich text.
Главное соблюсти чтобы сами исходники оставались попрежнему в plain text.
С Уважением Сергей Чикирев
Re[4]: Doxygen, JavaDoc со товарищи...
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 26.09.05 15:07
Оценка:
Здравствуйте, vladserge, Вы писали:

V>Есть такое ощущение, что это явление временное.

V>Когда руки дойдут, появятся нормальные редакторы кода которые вместо HTML-ных кракозябр будут выдавать нормальный Rich text.

Судя по скриншотам, JetBrain такое для шарпа готовит.
... << RSDN@Home 1.2.0 alpha rev. 617>>
AVK Blog
Re: Doxygen, JavaDoc со товарищи...
От: McSeem2 США http://www.antigrain.com
Дата: 26.09.05 15:46
Оценка: 6 (4) +2 -1 :)
Здравствуйте, c-smile, Вы писали:

CS>Мне кажется что концепт генераторов документации по исходному коду не работает.

CS>Вообще. Ни разу мне не удалось воспользоваться "сгенеряченной" информацией .

Как quick reference (и не более того!) — вполне себе катит. Но с некоторыми оговорками.

CS>Более того: В исходниках с коментариями под Doxygen тоже информацию

CS>потреблять сложно — нужно делать мозговой парсинг каждый раз.

Мое глубокое убеждение — исходник должен оставаться исходником. Референс, собираемый из комментариев, это конечно же хорошо. Но вот эта самая клизьма в виде XML, сводит всю идею на нет. Не хватает только HTML-ной табличной верстки непосредственно в коде.
Итак, цепочка рассуждений.
1. Исходник с комментариями — это прежде всего plain text.
2. Исходник с комментариями — первичен, референс — вторичен (образуется на основе исходника).
3. Исходник читается глазами в том виде, в каком есть.

Следовательно, любые таги и любое XML-like форматирование являются визуальным мусором. Максимум того, что допустимо — это plain-текст, отформатированный по тем же принципам, что и сам код. Если надо каким-то образом помечать аргументы или что-то еще, то эта пометка должна быть легкой-легкой. Почти не заметной. Что-нибудь типа Wiki-форматирования вполне бы подошло, но уж никак не эти блямбы "<param></param>".

А то, что сейчас преподносится от MS и Sun как великое достижение, является не более чем очередной навязанной клизьмой. Я не люблю жить со вставленной клизьмой. Кто-то любит. И даже убеждает всех остальных, как это полезно для здоровья.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Re[6]: Doxygen, JavaDoc со товарищи...
От: Alxndr Германия http://www.google.com/profiles/alexander.poluektov#buzz
Дата: 26.09.05 17:07
Оценка:
Здравствуйте, GlebZ, Вы писали:

GZ>Здравствуйте, c-smile, Вы писали:


GZ>Так писать мне ляниво Все в хедере.


В варианте c-smile определение something также находится в хедере
Re[2]: Doxygen, JavaDoc со товарищи...
От: gear nuke  
Дата: 26.09.05 17:38
Оценка:
Здравствуйте, McSeem2, Вы писали:

MS>любые таги и любое XML-like форматирование являются визуальным мусором. Максимум того, что допустимо — это plain-текст, отформатированный по тем же принципам, что и сам код. Если надо каким-то образом помечать аргументы или что-то еще, то эта пометка должна быть легкой-легкой. Почти не заметной. Что-нибудь типа Wiki-форматирования вполне бы подошло, но уж никак не эти блямбы "<param></param>".


А разве теги обязательны? Никогда их не использовал, только для формирования титульной и подобных страниц, но это всё в отдельных файлах лежит обычно.
А так комменты почти как и до доксигена, пара знаков припинания не сильно мешает:
/**
 * Does something. 
 * @warning sometimes craches :-)
 * @return foo value.
 */
int foo(
    int bar    ///< nice parameter.
    );

Не знаю только, кому это больше помогает — мне для понимания кода (?) или дяде, что бы потягивая кофе тыкать мышкой в chm, а в сорцы совсем не заглядывать.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Re[3]: Doxygen, JavaDoc со товарищи...
От: c-smile Канада http://terrainformatica.com
Дата: 26.09.05 17:51
Оценка:
Здравствуйте, gear nuke, Вы писали:

GN>Не знаю только, кому это больше помогает — мне для понимания кода (?) или дяде, что бы потягивая кофе тыкать мышкой в chm, а в сорцы совсем не заглядывать.


Вот и я о том. По моему гораздо проще смотреть коментарии в самой IDE
там еще есть другие фичи типа go to definition и class tree / namespaces.
Re[4]: Doxygen, JavaDoc со товарищи...
От: McSeem2 США http://www.antigrain.com
Дата: 26.09.05 18:21
Оценка:
Здравствуйте, c-smile, Вы писали:

CS>Вот и я о том. По моему гораздо проще смотреть коментарии в самой IDE

CS>там еще есть другие фичи типа go to definition и class tree / namespaces.

Например, в качестве тултипов очень хорошо помогает. Единственное, с чем я не согласен — так это с способом активации этой подсказки. Способ с наведением курсора мыши работает для кнопок-пимпок, но в исходном коде он является крайне невнятным и неудобным. Нужен клавиатурный способ, например, Alt-Up.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Re[5]: Doxygen, JavaDoc со товарищи...
От: McSeem2 США http://www.antigrain.com
Дата: 26.09.05 18:53
Оценка:
Здравствуйте, AndrewVK, Вы писали:

V>>Есть такое ощущение, что это явление временное.

V>>Когда руки дойдут, появятся нормальные редакторы кода которые вместо HTML-ных кракозябр будут выдавать нормальный Rich text.

AVK>Судя по скриншотам, JetBrain такое для шарпа готовит.


А можно их привести? Что-то сайте jetbrains не видать.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Re: Doxygen, JavaDoc со товарищи...
От: kwas Россия  
Дата: 26.09.05 20:05
Оценка: 10 (1) +3
Здравствуйте, c-smile, Вы писали:

Пойду от противного: почему это работает для меня.

1. Наличие опций SOURCE_BROWSER и INLINE_SOURCES делают из документации отличный браузер для кода. Лично для меня удобнее кликать по линкам в html или chm, при этом сразу просматривая код, чем плодить кучу окошек с исходниками в студии или еще где.
2. HTMLHelp — он есть! Со всеми индексами и поисками — только hhc.exe подавай.
3. Примеры использования также можно вставить — примеры здесь и здесь.

Ну и просто мысли.

Doxygen-документация, если ее пишете вы — она в первую очередь для пользователей вашей библиотеки, а уж потом для вас. И если вам лично она не нужна, то как насчет пользователей? Если же вы ее не пишете, то это уж как вам удобнее... Мне бы, например, разбираться с поделием под названием sipXtackLib без Doxygen'а с включенными SOURCE_BROWSER и INLINE_SOURCES было бы ой как лениво...

Документируя архитектуру, стараются обычно не сильно детализировать используемые абстракции. Благо, что это можно сделать на уровне модулей/пространств имен. То есть, под ссылку с названием "архитектура" можно положить достаточно высокоуровневую картинку, нарисованную в каком-нибудь Visio (при этом я предполагаю, что картинка, полученная reverse engineering'ом кода, явно избыточна). А документацию на строение отдельных модулей класть в описание соответствующих namespace'ов.
If a shark stops swimming, it will die. Don't stop swimming, Mr. Mulder.
Every epic equalizer is iso (c)
Re[6]: Doxygen, JavaDoc со товарищи...
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 27.09.05 06:36
Оценка:
Здравствуйте, McSeem2, Вы писали:

MS>А можно их привести? Что-то сайте jetbrains не видать.


Где то на форуме "Средства разработки" пробегало.
... << RSDN@Home 1.2.0 alpha rev. 617>>
AVK Blog
Re: Doxygen, JavaDoc со товарищи...
От: dmz Россия  
Дата: 27.09.05 06:47
Оценка:
CS>Мне кажется что концепт генераторов документации по исходному коду не работает.
CS>Вообще.

CS>Ни разу мне не удалось воспользоваться "сгенеряченной" информацией .

А почему, собственно?

CS>Более того: В исходниках с коментариями под Doxygen тоже информацию

CS>потреблять сложно — нужно делать мозговой парсинг каждый раз.
Опять же — не тема не раскрыта. Что именно помешало вопринимать информацию?

CS>Вопрос — я один такой?

CS>Если нет то давайте обсудим как жить дальше.

CS>Что есть такое полезная документация к коду, компоненту и т.д?

Ну например наличие javadocs, doxygen. Описание вызовов и примеры
использования.

По моему, большая часть жабских апи снабжены javadocs, и пользоваться
ими приходится довольно часто — это неотъемлемая часть жизни разработчика — особенно
когда начинаешь работать с незнакомым API. Разве информация о том, что метод делает, что
принимает, что возвращает, какие предусловия имеет и какие исключения бросает —
является бесполезной?

Конечно, наличие комментарив в коде может раздражать и визуально его захламлять —
но, ценность в том, что больше шансов что такие комментарии будут изменены при
рефакторинге — чего скорее всего не случится в случае, если описание хранится отдельно
от кода в сводобной форме.
Re[3]: Doxygen, JavaDoc со товарищи...
От: dmz Россия  
Дата: 27.09.05 06:53
Оценка:
CS>Ок. спасибо. Т.е. все-таки существуют системы в которых doxygen стиль документации работает.
CS>Вопрос: чем обусловлен успех в данном случае? Лучшей поддержкой среды?

Первое что я делаю, когда скачиваю неизвестное API (даже до того, как скачал) — это
смотрю javadocs / doxygen документацию, если она есть. Самый быстрый и понятный способ
оценить сразу дизайн (иногда отсеять явный трэш до скачивания), функционал и отчасти понять,
как пользоваться. Какая среда имеется ввиду? Какая среда нужна для просмотра документации,
кроме браузера?

CS>Гипотеза (личная, sic!): в С# и Java нет деления на .h и .cpp файлы — т.е.

CS>просто нет места где можно собрать документацию компактно. Поэтому
CS>сгененренный аннотированный список методов атрибутов — это собственно и
CS>есть .h файл — место где можно увидеть картину в целом и в компактном виде.

CS>Поправьте меня если я не прав.

IMHO, не прав. Аналог заголовков в жабе — это скорее интерфейсы классов.
Хорошо и правильно, когда они есть, и подробная документация, описывающая
поведение там как раз наиболее уместна — в принципе, когда код перегружен
комментариями, это раздражает.
Re[2]: Doxygen, JavaDoc со товарищи...
От: dmz Россия  
Дата: 27.09.05 07:01
Оценка: +2
MS>Следовательно, любые таги и любое XML-like форматирование являются визуальным мусором. Максимум того, что допустимо — это plain-текст, отформатированный по тем же принципам, что и сам код. Если надо каким-то образом помечать аргументы или что-то еще, то эта пометка должна быть легкой-легкой. Почти не заметной. Что-нибудь типа Wiki-форматирования вполне бы подошло, но уж никак не эти блямбы "<param></param>".

Это, безусловно, верно. Но держать эти комментарии в коде — единственный, наверное,
способ добиться их апдейта при изменениях кода, хоть как-то работающий.

Вроде, нормальные редакторы могут эти комментарии либо отображать бледно-серым, либо вообще скрывать —
так, что бы они не навязывались. Это хоть какой-то выход. По поводу wiki-синтаксиса — где-то согласен,
где-то нет. С одной стороны, он менее жирный, что есть хорошо. С другой стороны — он в данном случае
отображает скорее визуальное форматирование, чем модель предметной области — что есть плохо.
Re[7]: Doxygen, JavaDoc со товарищи...
От: GlebZ Россия  
Дата: 27.09.05 12:09
Оценка: +1
Здравствуйте, Alxndr, Вы писали:

A>В варианте c-smile определение something также находится в хедере

Зато реализация в cpp. Тратить столько Джоулей на работу по переключению окон, я неспособен. Лучше я кофе попью на компиляции.

С уважением, Gleb.
Re[3]: Doxygen, JavaDoc со товарищи...
От: McSeem2 США http://www.antigrain.com
Дата: 27.09.05 16:18
Оценка: 4 (2) +1 -1
Здравствуйте, dmz, Вы писали:

dmz>Это, безусловно, верно. Но держать эти комментарии в коде — единственный, наверное,

dmz>способ добиться их апдейта при изменениях кода, хоть как-то работающий.

Как говорит Алан Голуб в своей древней книжке, надо писать комментарии блоками — блок комментариев, блок кода и т.д. Комментирование каждой строки ужасно сбивает с толку — это все равно, что взять два текста и перемешать строки — строка из одного файла, строка из другого и т.д. А потом читать.

Стиль Doxygen, так же как и JavaDoc приводят имеенно к такому бардаку при описании классов. Исходник становится совершенно нечитаемым. Ну Java и C# сами по себе диктуют такой стиль, поскольку тело метода в том же месте и находится. Это, IMO, тоже плохо с точки зрения понимания общей архитектуры — за деревьями леса не видать. Чаще всего, нам, особенно на начальных этапах изучения, нам глубого пофиг информация о том, что значит каждый параметр и что делает эта функция. Нам важно прежде всего охватить общую концепцию — протокол взаимодействия с этим классом. Но из за обилия кода и комментариев, даже простейший класс раздувается до необозримых величин и становится совершенно нечитаемым. Близким к идеалу было бы что-то типа такого (некий псевдо-C++):
/// Описание класса и протокола взаимодействия с ним
/// ...
class foo
{
public:
   foo();
   void bar();
};

implement class foo
{
   /// Подробное описание конструктора
   /// ...
   foo()
   {
   }

   /// Подробное описание функции
   /// ...
   void bar()
   {
   }
}

В таком виде даже просто исходник безо всяких chm является вполне хорошей документацией. А если еще редактор позволяет подсвечивать информацию о функциях в виде тултипов — это вообще сказка. И исходник остается исходником — вполне целостным и с хорошо локализуемой информацией.

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


dmz>Вроде, нормальные редакторы могут эти комментарии либо отображать бледно-серым, либо вообще скрывать —

dmz>так, что бы они не навязывались. Это хоть какой-то выход. По поводу wiki-синтаксиса — где-то согласен,
dmz>где-то нет. С одной стороны, он менее жирный, что есть хорошо. С другой стороны — он в данном случае
dmz>отображает скорее визуальное форматирование, чем модель предметной области — что есть плохо.

Я же не сказал Wiki. Я сказал типа Wiki. Да даже TeX подошел бы.
/// \par{Параметр ля-ля-ля}
/// \ret{Возвращает такой-то результат}

Точнее сказать, описание параметров и прочие наиболее частые сущности надо оставить как в Doxygen "@param" — или как там? А для более продвинутых сущностей (формул и даже рисунков!) использовать TeX-like. Но самое главное — чтоб без фанатизма. Такст должен хорошо читаться не только после обработки, но и сам по себе. И никаких издевательств в виде XML!

И вообще, чаще нужен не Doxygen, а просто хорошо-кросс-линкованный HTML исходников. Вот, например:
http://antigrain.com/demo/alpha_mask2.cpp.html
Сделано с помощью AGDoc
Там не очень-то много чего линкуется, фактически только классы, структуры, енумы и т.д. Но зато совершенно не зависит от языка. А распарсить C++ — это вам не фунт изюму. Doxygen плоховато справляется.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Re[4]: Doxygen, JavaDoc со товарищи...
От: Зверёк Харьковский  
Дата: 27.09.05 16:34
Оценка: 23 (1) -1
Здравствуйте, McSeem2, Вы писали:

Маленькое замечание по поводу вот этого:

MS>....Комментирование каждой строки ужасно сбивает с толку — это все равно, что взять два текста и перемешать строки — строка из одного файла, строка из другого и т.д....


Я считаю, что это неверная аналогия. Комментарии, которые мне кажутся правильными, будут не "другим текстом", а дополнение к тексту программы. Т.е., та информация, которую нельзя выразить явно кодом — мы ее выражаем комментариями.
Типа
x = 1765; //magic number, source is bla-bla-bla;

//param value must be in [-100..200] range
int foo(in param);

и т.п.
Все остальное должен сообщать сам код.
"Я так думаю".
FAQ — це мiй ай-кью!
Re[5]: Doxygen, JavaDoc со товарищи...
От: McSeem2 США http://www.antigrain.com
Дата: 27.09.05 17:13
Оценка:
Здравствуйте, Зверёк Харьковский, Вы писали:

ЗХ>Я считаю, что это неверная аналогия. Комментарии, которые мне кажутся правильными, будут не "другим текстом", а дополнение к тексту программы. Т.е., та информация, которую нельзя выразить явно кодом — мы ее выражаем комментариями.

ЗХ>Типа
ЗХ>
ЗХ>x = 1765; //magic number, source is bla-bla-bla;

ЗХ>//param value must be in [-100..200] range
ЗХ>int foo(in param);
ЗХ>


Конечно, это разумно. Просто встречаются маньяки, которые комментируют каждую строку. Потом код меняется, комментарии рассинхонизируются и получается бардак. А вообще-то я подводил к тому, что комментарии перед прототипами методов тоже загрязняют класс.
    class stroker
    {
        . . .
        // Stroke parameters
        void line_cap(line_cap_e lc);
        void line_join(line_join_e lj);
        void inner_join(inner_join_e ij);
        void width(double w);
        void miter_limit(double ml);
        void approximation_scale(double as);
        void shorten(double s);
        . . .
    };


Здесь мы просто-напросто приводим список методов, как оглавление. А подробное описание должно быть где-то еще, перед имплементациями методов. И оно должно высвечиваваться в отформатированном виде в качестве тултипов.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Re[6]: Doxygen, JavaDoc со товарищи...
От: xvost Германия http://www.jetbrains.com/company/people/Pasynkov_Eugene.html
Дата: 27.09.05 18:10
Оценка:
Здравствуйте, McSeem2, Вы писали:

MS>А можно их привести? Что-то сайте jetbrains не видать.


Здеся:
http://www.jetbrains.net/confluence/download/attachments/13060/resharper20.jpg?version=1

Однако с сожалением надо признать что разработка приостановлена до лучших времен.
С уважением, Евгений
JetBrains, Inc. "Develop with pleasure!"
Re[4]: Doxygen, JavaDoc со товарищи...
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 27.09.05 22:06
Оценка: 33 (3)
Здравствуйте, McSeem2, Вы писали:

MS>Стиль Doxygen, так же как и JavaDoc приводят имеенно к такому бардаку при описании классов. Исходник становится совершенно нечитаемым. Ну Java и C# сами по себе диктуют такой стиль, поскольку тело метода в том же месте и находится. Это, IMO, тоже плохо с точки зрения понимания общей архитектуры — за деревьями леса не видать. Чаще всего, нам, особенно на начальных этапах изучения, нам глубого пофиг информация о том, что значит каждый параметр и что делает эта функция. Нам важно прежде всего охватить общую концепцию — протокол взаимодействия с этим классом. Но из за обилия кода и комментариев, даже простейший класс раздувается до необозримых величин и становится совершенно нечитаемым. Близким к идеалу было бы что-то типа такого (некий псевдо-C++):

<...>
MS>Doxygen вроде бы как позволяет такое делать, но на практике часто затыкается на шаблонах.

Ну, шаблоны со временем подтянутся. Doxygen-то не стоит на месте, развивается постоянно.

MS>Я же не сказал Wiki. Я сказал типа Wiki. Да даже TeX подошел бы.

MS>
MS>/// \par{Параметр ля-ля-ля}
MS>/// \ret{Возвращает такой-то результат}
MS>

MS>Точнее сказать, описание параметров и прочие наиболее частые сущности надо оставить как в Doxygen "@param" — или как там? А для более продвинутых сущностей (формул и даже рисунков!) использовать TeX-like. Но самое главное — чтоб без фанатизма. Такст должен хорошо читаться не только после обработки, но и сам по себе. И никаких издевательств в виде XML!

В Doxygen так и есть. Формулы записываются именно в синтаксисе LaTeX (чтобы их обработать на машине должен быть latex, dvips и gs).
Что до аргументов методов, то кроме @param в Doxygen есть еще два классных варианта:
void some_func(
    //! Этот комментарий будет описанием аргумента.
    int param1,
    int param2 //!< И этот так же.
    )
    { ... }


Вот маленькая иллюстрация того, что можно сделать с Doxygen. Для теста разместите все эти файлы в одном каталоге и запустите doxygen. В подкаталогах html и latex появится сгенерированная документация. Я использовал doxygen 1.4.3.

Файл test.hpp
/*!
    \file
    \brief Тестовый класс.
*/

#if !defined( TEST_HPP )
#define TEST_HPP

namespace test
{

class Test
    {
    public :
        Test();
        Test( int v );

        int v() const;
        void set_v( int v );

    private :
        int v_;
    };

} /* namespace test */

#endif


Файл test.cpp
/*!
    \file
    \brief Тестовый класс.
*/

#include "test.hpp"

/*!
    \brief Пространство имен для размещения тестового класса.

    Все основные текстовые классы размещаются в данном пространстве имен.
*/
namespace test
{

/*!
    \class Test "test.hpp"
    \brief Тестовый класс.

    Это тестовый класс для проверки возможности описания классов
    не в заголовочном файле.
*/

/*!
    \var Test::v_
    Значение, которое хранится в классе Test.
*/

/*!
    \brief Конструктор по умолчанию

    Устанавливает \a v_ в ноль.
*/
Test::Test()
    :    v_( 0 )
    {}

/*!
    \brief Инициализирующий конструктор.

    Назначает \a v_ указанное значение.
*/
Test::Test(
    //! Начальное значение для \a v_.
    int v )
    :    v_( v )
    {}

/*!
    \name Getter-/Setter-ы
    \{
*/
int Test::v() const
    {
        /*!
            \par Thread-safe?
            Да.
        */

        return v_;
    }

void Test::set_v( int v )
    {
        /*!
            \par Thread-safe?
            Нет.

            \attention
            В текущей версии не выполняет никаких проверок!
        */

        v_ = v;
    }
/*! \} */

} /* namespace test */


Файл mainpage.dox
/*!
    \page abstract Аннотация

    Задача этого теста -- показать возможности Doxygen по созданию
    полноценной документации. Толчком к этому послужило обсуждение
    на RSDN.ru (<a href="http://rsdn.ru/forum/Message.aspx?mid=1401092">Doxygen, JavaDoc со товарищи...</a>).
    В особенности, сообщение <a href="http://rsdn.ru/Users/Profile.aspx?uid=12737">McSeem2</a>
    (<a href="http://rsdn.ru/forum/Message.aspx?mid=1405520&only=1">Re[3]: Doxygen, JavaDoc со товарищи...</a>),
    в котором он описал, что хотел бы:
    - чтобы было меньше бардака, в частности, чтобы описания классов можно
    было делать не в декларациях классов (т.е. не в hpp-файлах);
    - чтобы оформление комментариев было в TeX-стиле.

    Но, на самом деле, в Doxygen все так и есть. Может быть с шаблонами и есть
    пока проблемы, но ведь Doxygen развивается. Со временем и шаблоны подтянутся.
*/

/*!
    \page install Инсталляция

    - Создайте файл test.hpp.
    - Создайте файл test.cpp.
    - Создайте файл Doxyfile следующего содержания:
    \include Doxyfile
    - Запустите doxygen (я использовал версию 1.4.3).
    - В подкаталогах html и latex будет создана необходимая документация.
*/

/*!
    \page desc Описание

    Здесь может быть какое-то сложное описание, разбитое на секции,
    подсекции и подподсекции.

    \section desc_sec1 Секция

    Как всегда, в примерах самое сложное -- это написать какой-то
    осмысленный текст.

    \subsection desc_sec1_subsec Подсекция

    Ну вот, опять та же проблема -- не хватает фантации.

    \subsection desc_sec1_subsec2 Еще одна подсекция

    Здесь вообще ничего не будет, кроме нескольких подподсекций.

    \subsubsection desc_sec1_subsec2_1 Мелкое описание

    Пример подподсекции.

    \subsubsection desc_sec1_subsec2_2 Еще одно мелкое описание

    Ну совсем мелкое.
*/

/*!
    \mainpage Тестовый проект для демонстрации возможностей Doxygen

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

    \subpage abstract

    \subpage install

    \subpage desc
*/


Файл Doxygen
# Doxyfile 1.4.3
PROJECT_NAME           = Test Project
OUTPUT_LANGUAGE        = Russian
EXTRACT_PRIVATE        = YES
FILE_PATTERNS          = *.dox *.?pp
EXAMPLE_PATH           = .


Еще один реальный пример использования Doxygen для создания не только On-Line Reference, но и описаний, можно найти здесь.
... << RSDN@Home 1.1.4 stable rev. 510>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[5]: Doxygen, JavaDoc со товарищи...
От: vladserge Россия  
Дата: 28.09.05 04:28
Оценка:
Здравствуйте, Зверёк Харьковский, Вы писали:

MS>>....Комментирование каждой строки ужасно сбивает с толку — это все равно, что взять два текста и перемешать строки — строка из одного файла, строка из другого и т.д....


ЗХ>Я считаю, что это неверная аналогия. Комментарии, которые мне кажутся правильными, будут не "другим текстом", а дополнение к тексту программы. Т.е., та информация, которую нельзя выразить явно кодом — мы ее выражаем комментариями.


а как много вещей можно гараздо компактнее, понятнее и изящнее описывать в виде небольших рисунков.( задумчиво так )
Даже сотня строк текста может не оказаться эквивалентной.
Например как описать проявления глюка на пользовательском интерфейсе с которым борется данный уасток кода? Только картинкой снэпшота: было так — полечили — стало так.
С Уважением Сергей Чикирев
Re[3]: Doxygen, JavaDoc со товарищи...
От: vdimas Россия  
Дата: 04.10.05 11:43
Оценка: 1 (1)
Здравствуйте, A.Lokotkov, Вы писали:

AL>Здравствуйте, AndrewVK, Вы писали:


AVK>>Не, меня твои выводы в очередной раз порадовали. Раз у тебя не вышло, значит вобще не работает. А ничего, что референс и по джаве и по .NET (и по львиной доле известных мне коммерческих библиотек для .NET) генерится автоматически?


AL>На этапе освоения языка (речь о java) или какой-то конкретной библиотеки, я думаю, мало кто пользуется референсом, -- информации мало и она не о том, о чем нужно. Приходится брать туторы и примеры кода (в том числе из туторов). Когда же язык или библиотека более или менее освоен, требуется знать точно, что происходит в том или ином методе некоторого класса. В результате референс опять не нужен, -- достаточно посмотреть исходный текст класса.


Ну и зачем каждый раз смотреть исходник класса, если мне только требуетс уточнить семантику, например, второго параметра в String::Substr(), который иной, чем в Java?

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

Что касается текущего проекта, то мы юзаем FAR (не тот, который типа Norton-shell, а тот, который MS Help 1.x и MS Help 2.0 ваяет), и свою автогенеренную доку из NDoc припаиваем прямо к установленному MSDN, и разработчикам всегда доступна справка прямо из редактора кода вижуал студии.
Re[7]: Doxygen, JavaDoc со товарищи...
От: WolfHound  
Дата: 04.10.05 13:37
Оценка:
Здравствуйте, xvost, Вы писали:

X>Однако с сожалением надо признать что разработка приостановлена до лучших времен.

И когда эти лучшие времена наступят?
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[3]: Doxygen, JavaDoc со товарищи...
От: VladD2 Российская Империя www.nemerle.org
Дата: 05.10.05 01:14
Оценка:
Здравствуйте, c-smile, Вы писали:

CS>Ок. спасибо. Т.е. все-таки существуют системы в которых doxygen стиль документации работает.

CS>Вопрос: чем обусловлен успех в данном случае? Лучшей поддержкой среды?

Выбором ХМЛ-я в качестве формата. Шучу, но в каждой шутке...

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

CS>Гипотеза (личная, sic!): в С# и Java нет деления на .h и .cpp файлы — т.е.

CS>просто нет места где можно собрать документацию компактно. Поэтому
CS>сгененренный аннотированный список методов атрибутов — это собственно и
CS>есть .h файл — место где можно увидеть картину в целом и в компактном виде.
CS>Поправьте меня если я не прав.

Хреновое предположение. Темболее что 99% С++-кода так же можно писать в .h-файлах.

CS>Еще раз для тех кто в танке — все вышеизложенное есть мое личное мнение.


А я думал вопрос.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Doxygen, JavaDoc со товарищи...
От: VladD2 Российская Империя www.nemerle.org
Дата: 05.10.05 01:14
Оценка:
Здравствуйте, c-smile, Вы писали:

CS>Где-нибудь еще:


CS>
CS>// something implementation...

CS>inline bool something() { return false; }
CS>


А дальше что? Ну, написал ты этот коментарий. Ведь чтобы его увидить нужно перейти к декларации. А в Шарпе ты наживмшь Ctrl+Shift и плучашь подсказку в которй уже есть текстовое описание не только функции, но и каждого ее параметра. Кстати, подсказки для FCL тоже сделаны с помощью ХМЛ-документации Шарпа.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Doxygen, JavaDoc со товарищи...
От: VladD2 Российская Империя www.nemerle.org
Дата: 05.10.05 01:14
Оценка:
Здравствуйте, dmz, Вы писали:

dmz>IMHO, не прав. Аналог заголовков в жабе — это скорее интерфейсы классов.

dmz>Хорошо и правильно, когда они есть, и подробная документация, описывающая
dmz>поведение там как раз наиболее уместна — в принципе, когда код перегружен
dmz>комментариями, это раздражает.

Поведение интерфейсов? Может быть их контракты?
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Doxygen, JavaDoc со товарищи...
От: VladD2 Российская Империя www.nemerle.org
Дата: 05.10.05 01:14
Оценка:
Здравствуйте, xvost, Вы писали:

X>Здеся:

X>http://www.jetbrains.net/confluence/download/attachments/13060/resharper20.jpg?version=1

А студия то где?

Кстати, палитрочка у вас жудкая.

X>Однако с сожалением надо признать что разработка приостановлена до лучших времен.


А че так?
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Doxygen, JavaDoc со товарищи...
От: VladD2 Российская Империя www.nemerle.org
Дата: 05.10.05 01:14
Оценка: -2 :)
Здравствуйте, McSeem2, Вы писали:

MS>А то, что сейчас преподносится от MS и Sun как великое достижение, является не более чем очередной навязанной клизьмой. Я не люблю жить со вставленной клизьмой. Кто-то любит. И даже убеждает всех остальных, как это полезно для здоровья.


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

А МС с Саном делают очень просто. Если потребители считают фичу полезной и требуют ее поддрежки, то реализуют ее и поддерживают.

А все кто бьется гловкой об стеночку увидив ХМЛ-коментрии, или Явские просто не очень вменяемые люди, ведь они могут их просто не испоьзовать. Мне чем-то эта ситмуация напоминает выступления дедушек на лавочке. Сидят и во все негодуют, мол "включил вчера телевизор, а там баба голая с мотрел и возмущался". Так и хочется сказать ему "дедунь, ты бы переключил канал то... чай не одни".

В общем, зачем оскорбляя других пытаться навязать им свое мнение? Они считаю это удобным вот и используют.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Doxygen, JavaDoc со товарищи...
От: McSeem2 США http://www.antigrain.com
Дата: 06.10.05 06:37
Оценка: :)
Здравствуйте, VladD2, Вы писали:

VD>Твои оскорбительные аналогии уже достали.

VD>Тебе явно по делу сказать нечего вот и бьешся в бессильной злобе видя что всем не твое мнение плевать.

Шутку понял. Смешно...
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Re[3]: Doxygen, JavaDoc со товарищи...
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 08.10.05 06:59
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>А МС с Саном делают очень просто. Если потребители считают фичу полезной и требуют ее поддрежки, то реализуют ее и поддерживают.


Это слегка ошибочное мнение. Пример: не было бы в жабке ни for /each/, ни enum-ов если бы .Net их не клюнул. И никакие бы потребители ничего не сделали. Ибо сантехники считали жабку вершиной совершенства. Оказалось нет — вершина это C# 1. Потом выяснилось, что C# 2. А теперь, похоже, C# 3 А теперь внимание вопрос: сколько потребителей считают полезными лямбды из C# 3?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[4]: Doxygen, JavaDoc со товарищи...
От: Sinclair Россия https://github.com/evilguest/
Дата: 08.10.05 07:20
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Это слегка ошибочное мнение. Пример: не было бы в жабке ни for /each/, ни enum-ов если бы .Net их не клюнул. И никакие бы потребители ничего не сделали. Ибо сантехники считали жабку вершиной совершенства. Оказалось нет — вершина это C# 1. Потом выяснилось, что C# 2. А теперь, похоже, C# 3 А теперь внимание вопрос: сколько потребителей считают полезными лямбды из C# 3?

Ага. Откуда компания зиппо знала, что людям потребуется столько зажигалок?
Вся разработка платформ — это попытки угадать, что потребуется людям.
Хотя, надо сказать, предварительная работа по выяснению, что не нравится сейчас, тоже проводилась.
Итак, разработчики в каждый момент имеют на руках следующие карты:
— список типичных задач, которые решают их потребители
— список недостатков существующих решений
— список достоинств конкурирующих решений
Последние два пункта ясны как день: выкидывай неудачное и воруй успешное. Лишь бы бюджета хватило, ну и технологические ограничения выполнились.
А вот первое — это как раз попытка угадать, где же там оно у нас это все. Ну вот, к примеру: при написании веб приложения дохрена всего интегрировать надо. Типичный набор: HTML/JS/CSS/С#/XML/SQL. Вот и возникает желание размыть границы.
Вообще сама технология .*SP уже является размытием границ между клиентским и серверным кодом. Во времена CGI все было четко видно: вот у нас код, который выполняется и что-то там в поток выводит. А вот у нас вывод этого кода, который тоже как-то работает, и нуждается в отладке.
А теперь берешь прямо в страничку спец.тег запузыриываешь, и все само происходит.
Остался еще SQL. Опять же — вот у нас код, который строку формирует, вот она эта строка. Уехала на сервер — вернулись какие-то данные.
В третьем шарпе, значит, принесут свет SQL в массы, т.е. в миддл-таер. Теперь мы прямо значит в тексте aspx странички будем писать всякие select и все такое в терминах объектной модели предметной области, заботливый компилятор за нас это все статически проверит, а DLink превратит в нормальный SQL-запрос (кто ж из любит, эти многоэтажные джойны с груп баями?). Красота. И знать не надо, что это лямбдой зовется.
А может к 2011 объявят DLink obsolete и "feature I suspected the very begginning to be too obscure to worth inventing".
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[5]: Doxygen, JavaDoc со товарищи...
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 08.10.05 09:38
Оценка:
Здравствуйте, Sinclair, Вы писали:

ANS>>Это слегка ошибочное мнение. Пример: не было бы в жабке ни for /each/, ни enum-ов если бы .Net их не клюнул. И никакие бы потребители ничего не сделали. Ибо сантехники считали жабку вершиной совершенства. Оказалось нет — вершина это C# 1. Потом выяснилось, что C# 2. А теперь, похоже, C# 3 А теперь внимание вопрос: сколько потребителей считают полезными лямбды из C# 3?

S>Ага. Откуда компания зиппо знала, что людям потребуется столько зажигалок?

Так это если есть попытка угадать. В случае Жабки таких попыток не было и они никаким образом не поощрались. А ведь говорилось о том, что Sun постоянно старается дать людям то, чего люди хотят. Я только на этот один момент и возразил.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[4]: Doxygen, JavaDoc со товарищи...
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.10.05 18:12
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

VD>>А МС с Саном делают очень просто. Если потребители считают фичу полезной и требуют ее поддрежки, то реализуют ее и поддерживают.


ANS>Это слегка ошибочное мнение. Пример: не было бы в жабке ни for /each/, ни enum-ов если бы .Net их не клюнул. И никакие бы потребители ничего не сделали. Ибо сантехники считали жабку вершиной совершенства.


А, черт его знает. С одной стороны согласен — МС подтокнул Сан к развитию Явы. Но с другой все же и Сантехники поняли свои ошибки. И подтолкнули его к этому пониманию именно требования пользователей. Жать только что поздновато, и жаль, что не все требования удовлетворяются. Хотя тут и Сантехников понять можно. Все же не все требования разумны, а им нужно делать фичи полезные для большинства. Иначе можно быстро угробить язык.


ANS>Оказалось нет — вершина это C# 1. Потом выяснилось, что C# 2. А теперь, похоже, C# 3 А теперь внимание вопрос: сколько потребителей считают полезными лямбды из C# 3?


"Считают полезными" может и не много. А вот оценят после некоторого времяни использования очень многие. Думаю, все кого нельзя назвать ламером оценят приемущества анонимных методов, а так же краткости и удобства синтаксиса лябд. Кстати, он все же не сокращен до предела. Все же имена параметров остались, что не будет приводить к удивлюнию среднего программиста (я надеюсь). А ведь могли ведь неявные имена использовать.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Doxygen, JavaDoc со товарищи...
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.10.05 18:12
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Так это если есть попытка угадать. В случае Жабки таких попыток не было и они никаким образом не поощрались. А ведь говорилось о том, что Sun постоянно старается дать людям то, чего люди хотят. Я только на этот один момент и возразил.


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

Неужели ты и в самом деле веришь, что Сан делает все назло навязывая частное мнение? Просто их видинее такое. И запросы своих клиентов они воспринимают сквозь призму своего видения.

Погляди как у нас на сайте частенько разгораются баталии на ровном месте. Есть стандарт ХМЛ. Его двигают и Сантехники, и MS, и IBM, и все кому не лень. Но у нас на сайте с завидной регулярностью пытаются смешать ХМЛ с дерьмом и предложить "намного лучшую альтернативу". И что МС с Саном должны прислушиваться вот к таким капризным клиентов небрезгающим любой демагогией и оскорблениями лиш бы доказать, что их каприз — это единственно правильное мнение? Да плевать МС и Сану на таких людей. Их ведь очень незначительный процент. Остальные или стоят на тех же позициях что эти мега-корпорации, или просто слепо верят им.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Doxygen, JavaDoc со товарищи...
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 08.10.05 18:44
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>смешать ХМЛ с дерьмом и предложить "намного лучшую альтернативу".


Начнём Лучшая ему альтернатива — полное его отсутсвие.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[7]: Doxygen, JavaDoc со товарищи...
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 08.10.05 22:32
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Погляди как у нас на сайте частенько разгораются баталии на ровном месте. Есть стандарт ХМЛ. Его двигают и Сантехники, и MS, и IBM, и все кому не лень. Но у нас на сайте с завидной регулярностью пытаются смешать ХМЛ с дерьмом и предложить "намного лучшую альтернативу". И что МС с Саном должны прислушиваться вот к таким капризным клиентов небрезгающим любой демагогией и оскорблениями лиш бы доказать, что их каприз — это единственно правильное мнение? Да плевать МС и Сану на таких людей. Их ведь очень незначительный процент. Остальные или стоят на тех же позициях что эти мега-корпорации, или просто слепо верят им.


МС до недавнего времени было плевать на Линуса и весь OpenSource вместе взятый.
Теперь отплевываются.
... << RSDN@Home 1.1.4 stable rev. 510>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[8]: Doxygen, JavaDoc со товарищи...
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.10.05 01:21
Оценка: :)
Здравствуйте, eao197, Вы писали:

E>МС до недавнего времени было плевать на Линуса и весь OpenSource вместе взятый.

E>Теперь отплевываются.

МС никогда небыло на них плевать. МС всегда боролся с обоими.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.