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