关于切换代码编辑器

Avatar of Chris Coyier
Chris Coyier

DigitalOcean 为您旅程的每个阶段提供云产品。 立即开始使用 200 美元的免费积分!

我相信你们很多人和我一样,多次切换过代码编辑器。 我认为我的第一个主要编辑器是 Coda。 然后,当我开始主要在本地工作时,我迁移到了 TextMate。 接着是 Sublime Text。 最近,我使用了 VS Code。 我敢打赌,您的旅程一定不同。 我认识很多非常喜欢 AtomBracketsWebStorm,甚至 BBedit 的人。 您只要做您想做的!

对我来说,在过去 12 年里,我换了四次编辑器,平均每三年换一次。 我不是那种快速迁移的人。 以下是我关于更换编辑器的想法。

迁移时,我需要花时间确保新编辑器与旧编辑器 **几乎一样**。

否则,我会最终讨厌它,并在一天或两天后切换回去。 我每次切换都会遇到这种情况。 每次切换后,我都会有一段时间短暂地回到旧编辑器,因为某些问题困扰着我,或者它影响了我的生产力,所以我放弃了。 (现在我知道自己会这样做,所以我不会因为 **一次** 短暂地回到旧编辑器就觉得我正在尝试的新编辑器 **永远** 不可能成功。)

我最近的一次切换是从 Sublime Text 到 VS Code。 我已经习惯了 Sublime Text 中的键绑定(例如,CMD+Shift+d 复制一行),因此很幸运的是,VS Code 支持这些绑定

令我惊讶的是,即使是我的 VIM 朋友在 VS Code 中也感到开心和舒适。 (有趣的事实:我们在 CodePen 中也拥有 键绑定选项。)

没有什么能过于令人反感。

在我第一次尝试切换时,我发现 VS Code 的 UI 太混乱了,项目内搜索功能有点慢且笨拙。 这些问题困扰着我,导致我短暂地回到了 Sublime Text。

在最近的一次切换尝试中(可能是我的第三或第四次尝试),我终于找到了一个 主题,我非常喜欢(稍微定制了一下),还找到了一些设置来清理 UI(我删除了空格指示符,因为它们对我来说太压迫了,并且用更酷的样式覆盖了那个强烈的蓝色页脚)。

在更多地使用项目内搜索功能后,我逐渐习惯了它。 我甚至可能比 Sublime 更喜欢它,因为侧边栏方法比打开一个新的结果选项卡更一致。 我发现跳转到行功能运行得更加一致,而且搜索感觉更像它应该成为的第一级功能。

另一个因素是 Emmet。 我非常肯定,如果我在没有 Emmet 的编辑器中编写 HTML 和 CSS,我会非常恼火,我会直接放弃使用另一个有 Emmet 的编辑器。 Emmet 甚至不是 VS Code 的扩展,它是 内置的

我乐于在成功切换 **之后** 进行一些小的更改。

一旦我 **真正** 完成了切换并全天候使用,**然后** 我就可以进行一些更改。 我可能会学习一些新的键盘命令。 我可能会添加一个扩展,为我提供以前从未有过的功能。 也许编辑器会以我现在愿意尝试的方式影响某些工作流程。

新编辑器最好有一些 **杀手级功能** 鼓励我切换。

如果它和旧编辑器完全一样,为什么要切换呢?

新编辑器需要更快(或者感觉一样快)。 或者看起来更好。 或者它应该有一些只在这个编辑器上可用的很棒的包。 最好是兼具所有这些功能。

在我最近的一次切换中,它就是 GitLens

它多么酷啊!

它应该有插件架构。

这意味着任何人都可以编写代码扩展编辑器。 我相当肯定,拥有插件架构(以及大量的社区支持)是任何编辑器成功的关键。 Sublime 的包管理器以及 VS Code 后续的内置包功能似乎至关重要。 不仅是为了功能,甚至是为了 编辑器的外观。 我不会使用一个我讨厌其外观的编辑器,但如果它的功能很强大,我会倾向于使用它。 对于基于插件的编辑器来说,这是一个无关紧要的问题。 开源 似乎也很明智。

小心那些陷阱。

其中一个问题就是拼写检查。 在 Sublime Text 中,它是一个在“查看”菜单下的选项。 我一直选中它,它一直进行拼写检查。

VS Code 中没有这个功能。 切换后这很危险,因为谁知道,我可能一直在犯错。 幸运的是,这个扩展 似乎正在起作用。 感谢扩展!

您的想法!

我认为询问大家在切换代码编辑器时会考虑什么会很有趣。 收到了很多回复。 我尽可能地挑选了一些,并重点关注了您提到的某一点。