Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 40
большая часть нас использует очень традиционные редакторы вроде Vim, Emacs, SublimeText, и даже Acme, а это не то, что большая часть людей думает как об IDE
Мне всегда казалось, что рефакторинг кода выполнять в IDE гораздо проще, чем просто в текстовом редакторе с подсветкой. Неужели это совсем не нужно ребятам, которые создали Go?
Сложно назвать эти программы «просто текстовыми редакторами с подсветкой».
Конечно, Go ведь рассчитан на по настоящему большие проекты, на которых любой статический анализ будет работать так долго, что быстрее весь код перешерстить вручную :-D
У «ребят, которые создали Go» была сильная нужда в рефакторинге, когда язык менялся (до версии 1.0) — и они пошли другим путём: написали утилиту gofix, которая умела сама исправлять «старый» код на «новый» во всей кодовой базе.
Рефакторить в разрезе файла или нескольких файлов — Vim так же вам позволит очень быстро выносить методы, переименовывать переменные и т.п. стандартными средствами редактора.
Если мы говорим о часто упоминаемом примере: переименовать название метода в огромном проекте. Да IDE с этим справится лучше, да с Vim нужно будет тупо grep-ать и sed-ить, а потом проверять при помощи компилятора, что ничего не сломалось. Но! Основаная проблема такого переименования как раз в не в том, чтобы код просто скомпилировался. Если проект действительно большой, то нужно решить еще две проблемы. Первое — это мета данные, всякие упоминания этого метода в help/json и т.п., с чем to IDE тоже поможет, но вручную проверить стоит. Проблема номер два — обозленные сотрудники, которым придется мерджить конфликты, подстраиваться под ваш рефакторинг. Если команда и проект действительно большие — вам этот рефакторинг еще пару месяцев будет вспоминаться. Лучшим способом отрефакторить такое — на уровне API построить новый метод и назвать другой obsolete, в этом случае IDE и vim отработают одинаково.
Если мы говорим о часто упоминаемом примере: переименовать название метода в огромном проекте. Да IDE с этим справится лучше, да с Vim нужно будет тупо grep-ать и sed-ить, а потом проверять при помощи компилятора, что ничего не сломалось. Но! Основаная проблема такого переименования как раз в не в том, чтобы код просто скомпилировался. Если проект действительно большой, то нужно решить еще две проблемы. Первое — это мета данные, всякие упоминания этого метода в help/json и т.п., с чем to IDE тоже поможет, но вручную проверить стоит. Проблема номер два — обозленные сотрудники, которым придется мерджить конфликты, подстраиваться под ваш рефакторинг. Если команда и проект действительно большие — вам этот рефакторинг еще пару месяцев будет вспоминаться. Лучшим способом отрефакторить такое — на уровне API построить новый метод и назвать другой obsolete, в этом случае IDE и vim отработают одинаково.
Рефакторинг не обязательно затрагивает интерфейс. Он может быть внутренним для модуля. Вы ведь не хотите сказать, что код в больших проектах никто не рефакторит?
> Он может быть внутренним для модуля.
Тогда это попадает под определение «Рефакторить в разрезе файла или нескольких файлов».
Тогда это попадает под определение «Рефакторить в разрезе файла или нескольких файлов».
Я все же считаю, что удобство несравнимо. Даже простом переименовании IDE позаботится о контексте, совпадающих именах, проверит, нет ли пересечений с существующими именами, проверит комментарии и другие ссылки на элемент. И потом — рефакторинг не ограничивается названиями. Скажем, я часто пользуюсь Pull / Push member рефакторингом.
Я понимаю, что в Notepad++ я тоже могу все это сделать, но с другими трудозатратами.
Я понимаю, что в Notepad++ я тоже могу все это сделать, но с другими трудозатратами.
Все так, я с вами соглашусь, лично для вас удобство не сравнимо, лично для вас трудозатраты будут другие.
Я лично не вижу проблем выполнить pull/push member рефакторинг в vim.
Я лично не вижу проблем выполнить pull/push member рефакторинг в vim.
Не расскажете, как вы это делаете? Cut/Paste?
Да, Select/Delete/Pase если быть точным.
Правильно ли я понимаю, что если оценивать трудозатраты как клики мышкой и нажатия клавиш на клавиатуре, IDE сделает это быстрее и удобнее (за счет некоторых других недостатков, таких как время запуска, невозможность запуска непосредственно на сервере, громоздкость и прочее)?
PHPStorm, скажем, еще исправляет объявление видимости членов класса, если это необходимо. Нет необходимости открывать файл, в котором содержится целевой класс и так далее.
PHPStorm, скажем, еще исправляет объявление видимости членов класса, если это необходимо. Нет необходимости открывать файл, в котором содержится целевой класс и так далее.
> IDE сделает это быстрее и удобнее
Вы правильно понимаете, для вас IDE сделает все быстрее и удобнее.
Если немного капнуть в этом вопросе: программисты в основном работают за время. То есть время — это главный показатель того, как программист эффективен. Если за N времени один программист может сделать то же самое в IDE, как другой в Vim — это значит, что они одинаково эффективны.
Лично я клавиши нажимаю намного быстрее, чем кликаю мышкой. Поэтому лично для меня удобнее и быстрее будет Vim.
Давайте перенесем контекст немного. На автомобили и автобусы. Как проще добраться с дома до работы?
Особенности автомобиля:
— Нужно знать как водить автомобиль.
— Сломается — нужно чинить самому.
— Есть проблемы с трафиком — нужно изучать самые короткие маршруты самому.
— Если переехать в другую точку или найти другую работу — достаточно легко подобрать новый маршрут.
Особенности автобуса:
— Необходимо ждать автобуса.
— Если автобус не приедет, то придется идти пешком.
— С трафиком проблем нет, с поломками проблем нет (другой придет), заботиться ни о чем не нужно.
— Если переехать в другую точку или найти другую работу — немного более проблематичнее подбирать новый маршрут, особенно если есть пересадки, нужно попробовать и посмотреть что будет быстрее.
Есть еще куча всяких персональных особенностей каждого: на автомобиле еще можно будет и в магазин заскакивать, а вот на автобусе во время движения можно читать. В общем, кого не спроси — у каждого будет свой набор пунктов, почему он выбирает именно этот вариант. Более того, иногда мы знаем уже, что на автобусе будет быстрее добираться о одном из случаев, но выбираем автомобиль, потому что нам так приятнее и удобнее. А иногда на автомобиле будет в 2 раза быстрее, но вот получить права на вождение, а так же купить автомобиль, решить где его парковать и т.п. Мы так же будем давать советы своим знакомым, что на автомобиле/автобусе будет быстрее, но слушать нас никто не будет, потому что у каждого свое мнение, и каждому удобно разное.
Вы правильно понимаете, для вас IDE сделает все быстрее и удобнее.
Если немного капнуть в этом вопросе: программисты в основном работают за время. То есть время — это главный показатель того, как программист эффективен. Если за N времени один программист может сделать то же самое в IDE, как другой в Vim — это значит, что они одинаково эффективны.
Лично я клавиши нажимаю намного быстрее, чем кликаю мышкой. Поэтому лично для меня удобнее и быстрее будет Vim.
Давайте перенесем контекст немного. На автомобили и автобусы. Как проще добраться с дома до работы?
Особенности автомобиля:
— Нужно знать как водить автомобиль.
— Сломается — нужно чинить самому.
— Есть проблемы с трафиком — нужно изучать самые короткие маршруты самому.
— Если переехать в другую точку или найти другую работу — достаточно легко подобрать новый маршрут.
Особенности автобуса:
— Необходимо ждать автобуса.
— Если автобус не приедет, то придется идти пешком.
— С трафиком проблем нет, с поломками проблем нет (другой придет), заботиться ни о чем не нужно.
— Если переехать в другую точку или найти другую работу — немного более проблематичнее подбирать новый маршрут, особенно если есть пересадки, нужно попробовать и посмотреть что будет быстрее.
Есть еще куча всяких персональных особенностей каждого: на автомобиле еще можно будет и в магазин заскакивать, а вот на автобусе во время движения можно читать. В общем, кого не спроси — у каждого будет свой набор пунктов, почему он выбирает именно этот вариант. Более того, иногда мы знаем уже, что на автобусе будет быстрее добираться о одном из случаев, но выбираем автомобиль, потому что нам так приятнее и удобнее. А иногда на автомобиле будет в 2 раза быстрее, но вот получить права на вождение, а так же купить автомобиль, решить где его парковать и т.п. Мы так же будем давать советы своим знакомым, что на автомобиле/автобусе будет быстрее, но слушать нас никто не будет, потому что у каждого свое мнение, и каждому удобно разное.
Ох, как же любят люди выдавать свою закостенелость за «мне так удобней». Нет, привычней, но не удобней, не быстрее и не точнее.
Помимо возможности работать с инструментами мышью (а не только запоминая 100500 хоткеев), IDE предоставляет более широкий их набор, чем простой текстовый редактор с подсветкой синтаксиса. Например:
1. Поиск места определения того или иного символа (а не места определения всех символов с похожими именами)
2. Переименование заданного символа (не затронув одноимённые символы)
3. Поиск всех мест использования заданного символа (причём использования в произвольной форме, от вызова как метода, до получения ссылки на него)
4. Сигнализация об ошибках (не только синтаксических, но и логических)
5. Быстрый показ документации по символу (в том числе показ списка доступных методов с их сигнатурами)
6. Интерактивная отладка (с исполнением по шагам, точками останова и инспекцией значений переменных)
Помимо возможности работать с инструментами мышью (а не только запоминая 100500 хоткеев), IDE предоставляет более широкий их набор, чем простой текстовый редактор с подсветкой синтаксиса. Например:
1. Поиск места определения того или иного символа (а не места определения всех символов с похожими именами)
2. Переименование заданного символа (не затронув одноимённые символы)
3. Поиск всех мест использования заданного символа (причём использования в произвольной форме, от вызова как метода, до получения ссылки на него)
4. Сигнализация об ошибках (не только синтаксических, но и логических)
5. Быстрый показ документации по символу (в том числе показ списка доступных методов с их сигнатурами)
6. Интерактивная отладка (с исполнением по шагам, точками останова и инспекцией значений переменных)
> Ох, как же любят люди выдавать свою закостенелость за «мне так удобней». Нет, привычней, но не удобней, не быстрее и не точнее.
А по мне так вы просто слепо судите о том, о чем понятие не имеете. Я 8 лет работал в Visual Studio & ReSharper. Около 2х последних в Vim. Лично мне кажется, что я могу сравнивать, а вы нет. У вас знаний Vim не достаточно, чтобы сравнивать оба способа разработки.
> IDE предоставляет более широкий их набор, чем простой текстовый редактор с подсветкой синтаксиса.
Это ВАШ список того, за что вы выбрали IDE. Я безумно за вас рад. Мне то что с него? Более того, больше половины, если прям так хочется, можно подкрутить и в текстовых редакторах.
А по мне так вы просто слепо судите о том, о чем понятие не имеете. Я 8 лет работал в Visual Studio & ReSharper. Около 2х последних в Vim. Лично мне кажется, что я могу сравнивать, а вы нет. У вас знаний Vim не достаточно, чтобы сравнивать оба способа разработки.
> IDE предоставляет более широкий их набор, чем простой текстовый редактор с подсветкой синтаксиса.
Это ВАШ список того, за что вы выбрали IDE. Я безумно за вас рад. Мне то что с него? Более того, больше половины, если прям так хочется, можно подкрутить и в текстовых редакторах.
Я работал с различными средами разработки, различными текстовыми редакторами и даже с текстовыми редакторами, к которым сбоку изолентой прикручиваются огрызки функциональности среды разработки. Так что я прекрасно знаю о чём говорю. И если мы закончили сравнивать наши половые органы, то было бы не плохо услышать от вас причины, которые вынудили вас дауншифтнуться до текстового редактора. Что-нибудь отличное от «для используемого мной языка ещё не запилили среду разработки» и «я чувствую себя кулхацкером, пользуясь инструментами, не поддерживающими мышь».
> Я работал с различными средами разработки
Вы меня не убедили.
> то было бы не плохо услышать от вас причины, которые вынудили вас дауншифтнуться до текстового редактора
Мне кажется, если бы первое было бы правдой, то этого вопроса бы не было.
> Что-нибудь отличное от…
Откуда вы взяли эти цитаты? Я такого не говорил.
Вы меня не убедили.
> то было бы не плохо услышать от вас причины, которые вынудили вас дауншифтнуться до текстового редактора
Мне кажется, если бы первое было бы правдой, то этого вопроса бы не было.
> Что-нибудь отличное от…
Откуда вы взяли эти цитаты? Я такого не говорил.
Вы правильно понимаете, для вас IDE сделает все быстрее и удобнее.
А для вас? Мы ведь оцениваем сейчас клики мышкой и набор клавиатурных команд. Мы с вами обсуждаем сейчас только рефакторинг. И я пытаюсь перевести дискуссию в некоторое объективное русло. Нравится или нет — вопрос субъективный. Я хочу сказать, что выполнение рефакторинга в IDE дает следующие преимущества над vim:
- Операция требует меньше нажатий клавиш на клавиатуре или перемещений мыши. То есть выполняется объективно быстрее
- IDE способна автоматизировать некоторое дополнительные действия, которые требуется выполнять программисту в процессе поскольку знает контекст выполняемой операции. Например, изменение области видимости членов класса. Это ускоряет операцию и снижает число ошибок, которые может допустить программист
- IDE способна понять, что выполнить какую-то операцию невозможно и сказать об этом программисту, поскольку знает контекст выполняемой операции. Это ускоряет операцию и снижает число ошибок, которые может допустить программист
Я понимаю вашу аналогию с автобусом и автомобилем, но она говорит лишь о том, что о вкусах не спорят. Я же пытаюсь привнести объективность в нашу дискуссию. Я понимаю, что вам нравится vim, а мне IDE. У каждого варианта есть достоинства и недостатки. Но мы обсуждаем конкретный случай — рефакторинг. Что эффективнее и удобнее использовать программисту в данном случае — vim или IDE?
Я с вами полностью согласен, у IDE есть свои прелести над текстовыми редакторами. Я работал около 8 лет в IDE, а именно Visual Studio + ReSharper. Без последнего причем был как без рук. Не понимал, как вообще в редакторе можно что-то писать. Последние два года работаю 99% времени в Vim. Я не говорю, что Vim лучше, у него есть свои прелести, за которые я его выбрал на данном этапе, и почему я с него не слезу. Но, отвечая на ваш вопрос.
> Что эффективнее и удобнее использовать программисту в данном случае — vim или IDE?
Мне эффективнее и удобнее использовать Vim. Вам, как я понял, IDE.
> Что эффективнее и удобнее использовать программисту в данном случае — vim или IDE?
Мне эффективнее и удобнее использовать Vim. Вам, как я понял, IDE.
Что для вас «эффективность и удобство»? Действительно ли у вас объективно уходит столько же времени в vim, сколько у меня в IDE на один и тот же более-менее сложный рефакторинг?
> Действительно ли у вас объективно уходит столько же времени в vim, сколько у меня в IDE на один и тот же более-менее сложный рефакторинг?
Я никогда лично не замерял, сколько времени у меня выходит выполнить какой-то рефакторинг в Vim, а сколько в чем-то другом. Более того, я лично не знаю сколько времени у вас на это уходит. Поэтому я на этот вопрос ответить не могу.
Сейчас скажу, что эффективность и удобство у меня на том же уровне, по ощущениям, как было с Visual Studio и ReSharper. Я так же полезен компании, в которой я работаю. Они довольны моей работой, а я доволен компанией, в которой работаю.
> Что для вас «эффективность и удобство»?
— Под эффективностью я понимаю: помощь моих тулов в решении поставленных задач в срок, который будет удовлетворять меня и моего работодателя.
— Под удобством я понимаю: использование приобретенных знаний в решении поставленных задач. Тут я замечу, что в совокупности vim+zsh+tmux+command line tools дают мне это удобство. Не только vim. Может быть, без дополнительных тулов мне vim был бы не интересен.
Я никогда лично не замерял, сколько времени у меня выходит выполнить какой-то рефакторинг в Vim, а сколько в чем-то другом. Более того, я лично не знаю сколько времени у вас на это уходит. Поэтому я на этот вопрос ответить не могу.
Сейчас скажу, что эффективность и удобство у меня на том же уровне, по ощущениям, как было с Visual Studio и ReSharper. Я так же полезен компании, в которой я работаю. Они довольны моей работой, а я доволен компанией, в которой работаю.
> Что для вас «эффективность и удобство»?
— Под эффективностью я понимаю: помощь моих тулов в решении поставленных задач в срок, который будет удовлетворять меня и моего работодателя.
— Под удобством я понимаю: использование приобретенных знаний в решении поставленных задач. Тут я замечу, что в совокупности vim+zsh+tmux+command line tools дают мне это удобство. Не только vim. Может быть, без дополнительных тулов мне vim был бы не интересен.
Я вас понял. Объективного диалога не получилось, к сожалению :)
Если вы хотите вести объективный диалог, то давайте сначала определимся с целями. Доказать, что IDE лучше Vim или наоборот? Не получится, да и не охото. Поговорить о том, почему люди выбирают одно или другое — наверное, можно. Давайте поставим вопрос точнее.
У нас просто диалог получается из разряда — вы мне пытаетесь навязать IDE, а я просто говорю, что люди, использующие текстовые редакторы делают выбор осознанно. Бесспорно вы можете найти 1000 случаев, где IDE будет лучше любого текстового редактора.
У нас просто диалог получается из разряда — вы мне пытаетесь навязать IDE, а я просто говорю, что люди, использующие текстовые редакторы делают выбор осознанно. Бесспорно вы можете найти 1000 случаев, где IDE будет лучше любого текстового редактора.
Цель — выяснить, можно ли рефакторинг в vim производить с той же скоростью и эффективностью, что и в IDE. Я не пытаюсь навязать вам IDE. Я пытаюсь доказать свою позицию о том, что в некоторых случаях возможности IDE превосходят возможности vim. А вы все время уклоняетесь от объективной дискуссии и переводите беседу в русло «мне нравится — вам не нравится».
Я ведь предложил вам клики и нажатия клавиш посчитать. Я предложил вам пояснить, как вы выполняете рефакторинг в vim. Вы фактически ответили, что все то, что за меня делает IDE, вы делаете руками. И вы называете это более эффективной работой и осознанным выбором.
Я согласен, что vim имеет свои преимущества. Однако, уж точно не при сложном рефакторинге кода.
Для того, чтобы переименовать namespace, мне в PHPStorm достаточно нажать Shift-F6 и ввести новое имя. А затем пару раз на Ok нажать для утверждения. И в результате все файлы будут переименованы, все ссылки во всех исходниках в проекте будут исправлены (со знанием контекста), необходимые папки будут автоматически созданы.
В vim эта операция гораздо более проблемна.
Хотите подискутировать — не съезжайте в субъективную плоскость. Я и сам работаю в текстовых редакторах вроде vim иногда.
Я ведь предложил вам клики и нажатия клавиш посчитать. Я предложил вам пояснить, как вы выполняете рефакторинг в vim. Вы фактически ответили, что все то, что за меня делает IDE, вы делаете руками. И вы называете это более эффективной работой и осознанным выбором.
Я согласен, что vim имеет свои преимущества. Однако, уж точно не при сложном рефакторинге кода.
Для того, чтобы переименовать namespace, мне в PHPStorm достаточно нажать Shift-F6 и ввести новое имя. А затем пару раз на Ok нажать для утверждения. И в результате все файлы будут переименованы, все ссылки во всех исходниках в проекте будут исправлены (со знанием контекста), необходимые папки будут автоматически созданы.
В vim эта операция гораздо более проблемна.
Хотите подискутировать — не съезжайте в субъективную плоскость. Я и сам работаю в текстовых редакторах вроде vim иногда.
Мне казалось, что мы уже ответили на большую часть вопросов.
> Я пытаюсь доказать свою позицию о том, что в некоторых случаях возможности IDE превосходят возможности vim.
Все так. Согласен. А в некоторых Vim превосходят IDE. Даже IDE иногда превосходят друг друга.
> Вы фактически ответили, что все то, что за меня делает IDE, вы делаете руками. И вы называете это более эффективной работой и осознанным выбором.
Именно. Не одним только рефакторингом мы занимаемся на работе. И как я уже сказал выше «Тут я замечу, что в совокупности vim+zsh+tmux+command line tools дают мне это удобство. Не только vim. Может быть, без дополнительных тулов мне vim был бы не интересен.»
> Я согласен, что vim имеет свои преимущества. Однако, уж точно не при сложном рефакторинге кода.
Да, согласен.
> Для того, чтобы переименовать namespace, мне в PHPStorm достаточно нажать Shift-F6 и ввести новое имя.
Я PHP не знаю, но по контексту: если взять Vim из коробки, то нужно будет делать все руками при помощи command line tools и Vim. Advanced Vim пользователь точно не будет это делать по одному файлу. Если эта операция будет частая, то можно даже написать Vim plugin (может быть уже есть? vimawesome.com/?q=php%20cat%3Alanguage), который пользуясь «find, sed, xargs, grep» выполнит то, о чем вы говорите. Если нет, то разово используя те же тулы выполнит это. Замечу, что это будет еще и приобретенным опытом, который в будущем позволит выполнять похожие операция в других языках или просто каких-нибудь файлах-данных.
> Я пытаюсь доказать свою позицию о том, что в некоторых случаях возможности IDE превосходят возможности vim.
Все так. Согласен. А в некоторых Vim превосходят IDE. Даже IDE иногда превосходят друг друга.
> Вы фактически ответили, что все то, что за меня делает IDE, вы делаете руками. И вы называете это более эффективной работой и осознанным выбором.
Именно. Не одним только рефакторингом мы занимаемся на работе. И как я уже сказал выше «Тут я замечу, что в совокупности vim+zsh+tmux+command line tools дают мне это удобство. Не только vim. Может быть, без дополнительных тулов мне vim был бы не интересен.»
> Я согласен, что vim имеет свои преимущества. Однако, уж точно не при сложном рефакторинге кода.
Да, согласен.
> Для того, чтобы переименовать namespace, мне в PHPStorm достаточно нажать Shift-F6 и ввести новое имя.
Я PHP не знаю, но по контексту: если взять Vim из коробки, то нужно будет делать все руками при помощи command line tools и Vim. Advanced Vim пользователь точно не будет это делать по одному файлу. Если эта операция будет частая, то можно даже написать Vim plugin (может быть уже есть? vimawesome.com/?q=php%20cat%3Alanguage), который пользуясь «find, sed, xargs, grep» выполнит то, о чем вы говорите. Если нет, то разово используя те же тулы выполнит это. Замечу, что это будет еще и приобретенным опытом, который в будущем позволит выполнять похожие операция в других языках или просто каких-нибудь файлах-данных.
Вот теперь это похоже на дискуссию ;) Спасибо.
Я сомневаюсь, что без построения AST можно корректно выполнить рефакторинг кода. Вам не встречались ссылки на vim плагины для любых языков, которые выполняют рефакторинг вроде rename method или rename variable? Мне было бы интересно взглянуть.
который пользуясь «find, sed, xargs, grep» выполнит то, о чем вы говорите.
Я сомневаюсь, что без построения AST можно корректно выполнить рефакторинг кода. Вам не встречались ссылки на vim плагины для любых языков, которые выполняют рефакторинг вроде rename method или rename variable? Мне было бы интересно взглянуть.
> Я сомневаюсь, что без построения AST можно корректно выполнить рефакторинг кода.
Корректно, наверное, нет, точнее может получится, что не всегда. С другой стороны и с IDE я никогда в жизни не выполню рефакторинг, не проверим потом код при помощи git diff. У меня нет 100% доверия к тулам, что они сделают все правильно. То есть перед тем, как я отправлю код в репозиторий — я точно буду глазами все просматривать.
> которые выполняют рефакторинг вроде rename method или rename variable?
Я вам привел ссылку выше на плагины для php vimawesome.com/?q=php%20cat%3Alanguage (может быть лучше или больше, я не знаю, я php не знаю). Там есть, например, какой-то php-refactoring.
С другой стороны, например, у меня есть плагин python-mode, который строит AST и может выполнить много разного рефакторинга, но я им не пользуюсь, просто не вижу смысла. Хватает vim команд и макросов с головой.
Корректно, наверное, нет, точнее может получится, что не всегда. С другой стороны и с IDE я никогда в жизни не выполню рефакторинг, не проверим потом код при помощи git diff. У меня нет 100% доверия к тулам, что они сделают все правильно. То есть перед тем, как я отправлю код в репозиторий — я точно буду глазами все просматривать.
> которые выполняют рефакторинг вроде rename method или rename variable?
Я вам привел ссылку выше на плагины для php vimawesome.com/?q=php%20cat%3Alanguage (может быть лучше или больше, я не знаю, я php не знаю). Там есть, например, какой-то php-refactoring.
С другой стороны, например, у меня есть плагин python-mode, который строит AST и может выполнить много разного рефакторинга, но я им не пользуюсь, просто не вижу смысла. Хватает vim команд и макросов с головой.
Кстати, попробуйте как-нибудь в vim переименовать namespace при использовании PSR-0 / PSR-4 загрузчика.
Это здорово! Чем vim с возможностями IDE будет отличаться от IDE? ;) Думаю, ничем!
Будет здорово, если вы добавите немного фактов к вашему заявлению.
Вверху, если вы заметили, мы обсуждали преимущества IDE в плане рефакторинга. В настоящий момент PHPStorm в этом плане имеет гораздо больше возможностей, чем vim с любыми плагинами. При работе с большими проектами, архитектура которых не является статичной, для меня IDE предпочтительнее.
Скорость набора текста для меня никогда не являлась приоритетом. Если это приоритет в программировании для вас — я думаю, вы что-то делаете неправильно. Или, может быть, я вас неверно понял? Вы могли бы привести конкретный пример, в котором скорости IDE для вас недостаточно в сравнении с Sublime или vim?
Вверху, если вы заметили, мы обсуждали преимущества IDE в плане рефакторинга. В настоящий момент PHPStorm в этом плане имеет гораздо больше возможностей, чем vim с любыми плагинами. При работе с большими проектами, архитектура которых не является статичной, для меня IDE предпочтительнее.
Скорость набора текста для меня никогда не являлась приоритетом. Если это приоритет в программировании для вас — я думаю, вы что-то делаете неправильно. Или, может быть, я вас неверно понял? Вы могли бы привести конкретный пример, в котором скорости IDE для вас недостаточно в сравнении с Sublime или vim?
но я все равно не могу доверять такие операции IDE, поэтому для меня разницы особо нету
Почему? PHPStorm выполняет операции вроде rename namespace довольно корректно. Или были проблемы?
Для ответа на мой вопрос нужно сравнить возможности рефакторинга vim и PHPStorm по всему спектру возможностей. А мы с вами пока в частности уперлись. Но даже если этот вопрос разрешится, в IDE еще много всего интересного. Инспекции кода, интеграция различных инструментов, понимание структур кода фреймворков, удобная отладка и тестирование и т.д.
Я понимаю, что если у вас голый код в сферическом вакууме, то vim быстрее. Я и сам бывает в Notepad++ пописываю что-то (все реже и реже, правда). Но когда речь идет о серьезном проекте…
Эта книга уже едет ко мне
C++ мертв, да здравствует C++, по крайней мере в среде веб приложений, похоже я понимаю теперь, кто конкурент java и C#, по правде говоря мне всегда нравилась обработка ошибок, а не тупое try except! обработка ошибок в стиле C-style все таки вернулась!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Интервью: Брайан Керниган и Алан Донован