Учимся продавать самопал

[Пепел Феникса]

вам так бомбит от необходимости проверять данные?

открытый код != говно-код.

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

как я говорил, нафиг такая библиотека нужна?

Сообщение от LV1974

Если фигура не поместилась в экран - то "это уже плохо, нафиг такая библиотека нужна".
Тогда обрабатывайте выход фигуры за пределы экрана на клиентской базе.

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

Сообщение от LV1974

Давайте доведём это до идиотизма и сделаем assert!

ассерты и полезны в отладке, неволнуйтесь, они стоят где нужно

и да, про профессора вы зря, опыт жизненный, а не от преподов.

[LV1974]

Пепел Феникса, я прошу прощения за некоторые свои необдуманные слова. Тем более, что этот вопрос выходит за рамки темы.
Благодарю за внимание к теме продажи самопала.

[LV1974]

Сообщение от MihalNik

А если её найдёт злоумышленник? Открытое ПО и предоставление исходного кода ответственным лицам - это разные вещи.

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

Вывод такой:
На первых версиях - можно немного схалтурить. Тогда лучше сразу сказать - что это альфа-версия или сигнальная.
Затем надо кинуть силы на поддержку - обрабатывать все вопросы и нарекания.
А после этого - надо найти в себе силы, чтобы выпустить следующую версию.
Это определяется прикладной востребованностью. Сужается специфика. Поэтому работать будет проще для узкого круга задач.
Конечно, навёрстывать потом некоторые вопросы - тоже придётся.

[LV1974]

Предлагаю рассмотреть такую стратегию:

Несколько лет я занимаюсь написанием встраиваемых векторных редакторов.
Сейчас я считаю, что ядро редактора - должно быть открытым.
Эта идеология прямо противоположна ActiveX.
Суть открытого ядра редактора в том, что его расширения могут быть закрытыми и вообще очень разными.
Кто-то может добавить графические трансформации.
Другой - добавит инженерную графику.
Третий - добавит визуальные эффекты.
Четвёртый - редактирование текста.
Ну и так далее - пошло и поехало.
Выгода - в мультипликации возможностей.

Что скажите о такой стратегии?

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

[Pavia]

1) Исключения кидать не надо, надо возвращать код ошибки.
Обработчик исключения сохроняет и восстанавливает только стек. Поэтому после исключения состояния объектов могут оказаться неправельными, выходящие за допустимые значения.
2) По мимо безопасности кода есть ещё и понятия устойчевости/стойкости.
3) Никто чужой исходник править небудет. Просто что бы прочитать чужой код требуется приложить немало усилий говорят в 10 раз больше чем для личного.
4) Поповоду null и профессора. Это не профессор это личный опыт когда плавучий баг нельзя было победить полгода. Так как стек недовал результатов. И это не еденичный случай.
5) Писать код с минимом проверок это искусство. К примеру можно разделить на фасад и реализацию. В первом делаете все проверки во втором пишете базовый алгоритм. Так же помогает инвесия управления и др шаблоны.
6) Открытый код легко позволяет оценить его качество. Более того сейчас очень часто можно встретить в репозитарее кода тесты для проверки его работы. Это тоже своего рода показатель качества и может играть роль приманки для клиентов.

[Пепел Феникса]

Сообщение от LV1974

Эта идеология прямо противоположна ActiveX.

ActiveX не имеет отношения к открытости код, вот ни капли.

Сообщение от LV1974

Что скажите о такой стратегии?

для всего этого нужно продуманная структура расширений.
открытый код тут отдельный фактор.

Сообщение от Pavia

Исключения кидать не надо, надо возвращать код ошибки.
Обработчик исключения сохроняет и восстанавливает только стек. Поэтому после исключения состояния объектов могут оказаться неправельными, выходящие за допустимые значения.

Код ошибки VS исключение это отдельная тема.

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

[LV1974]

Мне не хотелось разводить холивар по поводу исключений и кодов ошибок.
Поэтому я извинился за свою категоричность.
Однако сейчас стало интересно - есть ли чёткий критерий для применения исключений или кодов ошибок?

Опыт подсказывает, что это зависит от специфик проекта.
Например, в одной задаче мне пришлось использовать: БД, машину скриптов и почтовую пересылку. Так в той задаче наша команда увлеклась именно исключениями и их обработкой с ведением лога. В других моих проектах такого не было.

[pu4koff]

Коды ошибок в 2017 году? Еще живы те, для кого исключения - это слишком много накладных расходов?

[Alar]

Сообщение от pu4koff

ще живы те, для кого исключения - это слишком много накладных расходов?

Да

http://www.programmersforum.ru/showt...278073&page=28

[LV1974]

Сообщение от Пепел Феникса

ActiveX не имеет отношения к открытости код, вот ни капли.
....
для всего этого нужно продуманная структура расширений.
открытый код тут отдельный фактор.

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

Более подробно я постараюсь написать об этом в теме про Интерактивную геометрию.
http://www.programmersforum.ru/showthread.php?t=314706
Ну это когда будет возможность показать и покрутить что-то конкретное.