Re: Среды разработки
On Tue, 16 Oct 2012 21:53:38 +0400
"Артём Н." <artiom14@yandex.ru> wrote:
> >> Вот я думаю, что она должна быть в правом нижнем углу, выровнена по правой
> >> границе с верхней кнопкой, причём находиться чуть выше нижней границы воон того
> >> "бевела", выделяющего группу контролов.
> > Вот это условие как раз лучше описывается именно словами, а не языком
> > жестов для глухонемых.
> А когда таких слов очень много?
Мало этих слов. Ничуть не больше, чем CBuilder в Object Inspector-е
показывает. Причём в текст попадают только нужные, отличающиеся от
дефолтного значения, а не всё подряд, что в этом окне выводится.
> Может, проще посмотреть на интерфейс? "Лучше один раз увидеть", не?
Смотри, кто ж мешает. Как надоест тестировать окошко после каждой
незначительной правки, так задумаешься, что неплохо бы подойти и с
другой стороны.
> > К примеру, большинство набросанных в визуальном
> > редакторе сибилдера формочек начинает съезжать при изменении размеров
> > окна или шрифта.
> Это ошибка не среды, а кривые руки и непредусмотрительность "дизайнера интерфейсов".
> Есть такое свойство, как Anchors. И ничего не съезжает.
Ага, кнопки справа в окошке дизайнера, анчоры — слева в object
inspector-е. Вот и крути головой туда-сюда, высматривая соответствия.
Неудобно.
> >> Но, при сложной форме, в текстовом описании интерфейса ещё проще запутаться.
> > Разбивай построение интерфейса на отдельные небольшие функции с внятными
> > названиями. Рисовалка такой возможностив принципе не предоставляет.
> Ну, думаю, предполагается, что пользователь может удержать не очень большое
> число элементов в фокусе внимания. И надо создавать интерфейс так, чтобы он не
> был перегружен. Он сам разбивается на отдельные компоненты.
То ты говоришь про сложную форму, то говоришь, что они не нужны.
Определись.
> > Зачем? Зачем эта глупая привязка к IDE? Задачи прекрасно решаются и так.
> Почему глупая?
Потому что расход ресурсов на непроизводительные действия.
> Мне надо:
> 1. Написать. Удобно, быстро с отступами и подстановками. Создать интерфейс.
Хороший текстовый редактор. А их всего два.
> 2. Собрать часть и запустить на разных этапах (не переписывая Makefile, при
> добавлении модуля).
> 6. Проверить модуль с разными наборами данных.
Unit testing.
> 3. Попасть на строку, на которой программа вывалилась (именно на ошибку, а не на
> warning).
Команда «:номер-строки» в виме. При компиляции из самого вима оно
перескакивает автоматом.
> 4. Посмотреть переменные в этом месте. Посмотреть подсказки (не просто
> Segmentation fault).
> 5. Пройти дальше на шаг, поменять значения переменных. Изредка посмотреть
> дизассемблерный листинг.
Это делает gdb. Я даже ставил себе clewn для интеграции оного в vim, но
не прижился он у меня из-за неиспользуемости.
При правке из отладчика рассматриваемый контекст ограничен одной
функцией, потому годится для совсем очевидных ошибок. В других же
случаях решает ошибку долгая медитация над кодом, по сравнению с которой
10 секунд на запуск gdb роли не играют.
Кстати, очень грустно выглядит программист, который в отладчике ловит
ошибку, проявляющуюся не ранее 135-й итерации цикла. Столько лишних
нажатий на клавиши.
> 7. Проверить программу на утечки, использование неиниц. переменных, обращения за
> границы и прочее. Мне нужна строка, где происходит обращение. И подсказка: куда
> и кем.
valgrind. Он очень практично совмещается с unit-тестами.
> 8. Сохранить изменения и записать версию.
hg ci в терминале. Ну или прямо из вима. Можно и с окошком.
> Я уж не говорю о интеграции с какой-то CASE-фигнёй или штукой уровня выше (тут
> как-то писали про cucumber)...
> И ещё много что.
Говорить надо о том, что используется, а не баззворды с конференций
повторять.
> Да, "всё решается так". Но не слишком ли это..? Если бы всё было так славно и
> удобно, вообще, IDE бы придумывали?
То есть IDE придумали боги, а нам, простым смертным, надо в него
уверовать ибо постичь мы не в состоянии? Или откуда тогда следует
желание пользоваться чем-то только из-за того, что оно существует?
--
Alexander Galanin
Reply to: