Как я могу объективно оценить производительность редактора?

Если вам нравится писать код в vim, это уже хорошая причина использовать vim.

Что хорошего в инструменте, который повысит вашу продуктивность на 2% (согласно некоторым исследованиям), но который вам не понравится? Говорю вам, работа с инструментами, которые вам нравятся, чертовски важно!

Почему бы просто не попробовать несколько разных редакторов и посмотреть, сможете ли вы уведомление повысить производительность труда. Если вы этого не сделаете, выберите тот, который вам больше всего нравится, если вы это сделаете, вам нужно будет решить, перевешивает ли прирост производительности то счастье, которое вы испытываете при использовании vim.

Вы также можете рассмотреть возможность использования разных редакторов для разных фреймворков / языков. Я использую vim для большей части своего программирования на C и Perl, другой редактор для нетривиальных приложений Java и еще один редактор для разработки в Rails, я еще не нашел универсального редактора.

Чтобы сделать это объективно, вам понадобится что-нибудь измеримое.

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

Еще я пристрастился к модели ввода Vi, уверен, что она делает меня более продуктивным.

Мне неудобно пользоваться другими редакторами. Когда я использую Visual Studio, мне действительно нужен ВиЭму, в Eclipse я использую viPlugin и так далее.

Некоторое время назад я был пользователем Emacs, теперь я не могу использовать его без Гадюка.

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

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

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

Я бы сказал с огромной степенью уверенности, что если вы достаточно глубоко погрузились в Vim, чтобы разочароваться в других редакторах, любой выигрыш в производительности от перехода, вероятно, будет очень небольшим.

Я бы посоветовал просто измерить ваш фактический результат:

• Используйте vim в течение одной недели и измерьте фактический результат. Сохраните результат как V.
• Используйте другой редактор на одну неделю и измерьте фактический результат. Сохраните результат как E.

Если V <E, то другой редактор имеет лучшую производительность, иначе vim - лучший выбор для вас.

Обратите внимание, что самая сложная часть - это измерение фактического выхода. Например, общее количество строк кода или размер вывода diff за неделю могут быть плохими методами. Вдобавок может оказаться, что в течение первой недели вы писали простой код, а в течение второй недели вы пытались исправить действительно серьезную ошибку. В результате вы действительно можете сравнивать одну рабочую неделю с другой, а не от одного редактора к другому.

Я думаю, это сводится к выяснению что вы пытаетесь достичь, а затем выбираете как можно более объективный метод измерения для этого. Затем определите, какой редактор получает лучший результат.

Я бы даже не стал измерять фактическое использование редактора. Редактор с действительно высокой производительностью может быть реализован как dd if=/dev/urandom bs=1M count=1 > code.cpp, но изменения настолько велики, что качество вашего результирующего кода сильно отстой. Если результат хороший, никого не должно волновать, как вы его испустили.

Фактическое использование редактора должно учитываться только в том случае, если вы физически не можете использовать редактор в течение длительного времени; например, если редактору постоянно требуется переключаться между клавиатурой и мышью, у вас могут возникнуть проблемы с RSI, несмотря на то, что в краткосрочной перспективе этот редактор обеспечит наилучшую производительность.