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

_FR>>Так вот если правила оформления кода позволяют такое (опускать кавыки), то не редко можно увидеть ошибки
AVK>Использую такой стиль уже лет 6 — описанной проблемы не было ни разу. А при установленном решарпере добится такого форматирования это специальным образом поизвращаться надо.

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

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

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

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

Здравствуйте, http://chabster.blogspot.com/, Вы писали:


HCB> А смысл? Я уверен, что для большинства проектов не руководствуются требованими к интерфейсу, а берут "самую крутую" библиотеку и за рамки ее функционала не вылазят. Кому нужен этот скиннинг тормозящий? Кому нужны монстрообразные контролы, напичканные функционалом, который нужно выбрасывать постоянно?

HCB>Если нужен конкретный элемент управления, я выбираю самый легкий контрол согласно требованиям. И если такого не нахожу — менеджмент, как правило, принимает правильное решение писать либо с нуля, либо на основе стандартного элемента управления (WinForms).

HCB>Месяца три назад решили использовать TreeList. Правда, от оригинального трилиста мало что осталось. И, поверь, копаться в их недокументированных исходниках — та еще радость. Если от контрола требуется то, чего нет в их примерах — туши свет. К примеру, нам нужен был TreeList, данные которого обновляются в режиме реального времени. Я поменял половину его исходников, чтобы убрать дикие тормоза, связанные с пересчетом всей геометрии при изменении значения одной ячейки. Причем в саппорте сказали, мол "контрол слишком сложный, поэтому пересчет и связанные с ним тормоза убрать нельзя". Остается лишь поблагодарить ДевЕкспресс за всю ненужную ерунду и связанный с ней еффорт. Для интереса — полистай саппорт. Там везде или "нельзя" или "этот дефект by design" или просто морозятся от ответа на поставленный вопрос.

забавно. Вам же приводили пример с бензопилой. Могу его расширить. Например, если вы купили пилу и стали ее использовать для того, чтобы колоть дрова, или копать землю — и при этом требовать от производителя бензопилы, чтобы он улучшил данные свойства. Как думаете, куда вас пошлет производитель пилы? .
Приблизительна таже история из компонентами. Невозможно написать универсальный TreeList или Grid, который одинаково хорошо будет работать при абсолютно разных сценариях. Как правило, выбираются основные направления и реализуется их максимальная поддержка. Разумеется никто изначально не закладывался на real-time дерево — предпологалось, что это будет либо статика, либо постепенно обновляемое/редактаруемое дерево. Что устраивает 99% его пользователей.


HCB>Форматирование кода — вовсе не проблема. Проблема в качестве кода и полнейшем отсутствии документирования (я даже не о комментариях). Представь, что контролы WinForms документированы строго на уровне свойств дизайнера. Как можно использовать такую библиотеку?

Понятие "качества" у всех очень разное. А документирование кода, это один из видов его хренового качества — если код нуждается в документации, значит он странно написан.

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

AVK>Здравствуйте, Константин Л., Вы писали:

КЛ>>3. исходники отвратительны в плане оформления

AVK>Есть подозрение, что они чем то обработаны. Ну не верю я, что в таком большом проекте нет ни одной строчки комментария.
Скажем так, это предположение отчасти верно. Но комментариев в "реальном" коде минимум. Это как правило, либо закомментаренный старый код,
либо //TODO . Так как в 99% случаев код документирует себя сам. Или юнит тесты помогают дополнить картину.
(о вырезании документации из кода: документация генерируется не из кода, а из sql базы)

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

M>Понятие "качества" у всех очень разное. А документирование кода, это один из видов его хренового качества — если код нуждается в документации, значит он странно написан.

А как же на счёт пред\пост условий? Прикажете смотреть так: "Ага, метод делает такой-то if, значит ему можно передавать это вот"? Бред: Коментарий нужен, как минимум, для описания контракта. Так же, нестандартные и неявные решения рекомендуется коментировать, а то они в первую очередь падут жертвой рефакторинга.

Здравствуйте, AngeL B., Вы писали:
AB>... есть Evaluation ... полностью функциональна ... нет исходников, при запуске программы выдается Evaluation окно и в отчетах внизу надпись соответсвующая.

Я правильно понимаю, что evaluation-версии devexpress-компонентов неограничены по времени использования?

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

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

M>>Понятие "качества" у всех очень разное. А документирование кода, это один из видов его хренового качества — если код нуждается в документации, значит он странно написан.

_FR>А как же на счёт пред\пост условий? Прикажете смотреть так: "Ага, метод делает такой-то if, значит ему можно передавать это вот"? Бред: Коментарий нужен, как минимум, для описания контракта. Так же, нестандартные и неявные решения рекомендуется коментировать, а то они в первую очередь падут жертвой рефакторинга.

для этого ведь и существуют юнит тесты. — чтобы избегать таких проблем.
в компонентах, комментарии я делал только в случае "//todo " или workaround'a чужих проблем — в данном случае MS.

Здравствуйте, Константин Л., Вы писали:

КЛ>Здравствуйте, AngeL B., Вы писали:

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

AB>>Мы пользуемся этим (DevExpress).
AB>>Просто в восторге...

КЛ>отстой. лучше чем component one & infragictics, но все же отстой:

КЛ>1. запутанная и часто неудобная объектная модель
КЛ>2. чтобы спрятать одну кнопку зачастую приходится порождать по 5 классов.
КЛ>3. исходники отвратительны в плане оформления
КЛ>4. забывают делать очевидные вещи для extensibility

КЛ>Кароче, имхо они умеют только хорошо рисовать

КЛ>Из плюсов — адекватный и быстрый саппорт

Это ты просто Stingray не пробовал

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

M>Приблизительна таже история из компонентами. Невозможно написать универсальный TreeList или Grid, который одинаково хорошо будет работать при абсолютно разных сценариях.

Верная мысль. Собственно, два разных компонента с общей базой завсегда предпочтительнее одного монстра. Чем мне собственно и не нравится дизайн VCL/Winforms/etc.

Здравствуйте, Mr.Cat, Вы писали:

MC>Я правильно понимаю, что evaluation-версии devexpress-компонентов неограничены по времени использования?
Ограничены 30 календарными днями.

Здравствуйте, AngeL B., Вы писали:

AB>Здравствуйте, Mr.Cat, Вы писали:

MC>>Я правильно понимаю, что evaluation-версии devexpress-компонентов неограничены по времени использования?
AB>Ограничены 30 календарными днями.
Согласно лицензии.

Здравствуйте, AngeL B., Вы писали:

MC>>>Я правильно понимаю, что evaluation-версии devexpress-компонентов неограничены по времени использования?
AB>>Ограничены 30 календарными днями.
AB>Согласно лицензии.

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

Здравствуйте, Mr.Cat, Вы писали:

MC>Здравствуйте, AngeL B., Вы писали:

MC>>>>Я правильно понимаю, что evaluation-версии devexpress-компонентов неограничены по времени использования?
AB>>>Ограничены 30 календарными днями.
AB>>Согласно лицензии.

MC>Спасибо. Просто было желание воспользоваться одним из компонентов для реализации прототипа приложения, и ограничение в 30 дней совсем некстати приходится.
ограничение прописано только в тексте. программных ограничений нет.

Здравствуйте, mike27, Вы писали:
M>ограничение прописано только в тексте. программных ограничений нет.
Это уже лучше. Но все же попробую уложиться в месяц. Как-никак надо проявлять уважение к разработчикам.