内容简介:I’ve spent the last couple weeks diving head first into the world of vim. At times I’ve felt like a complete badass zipping my way around the terminal, editing large chunks of code with ease, and other times… well not so much.For those that can’t squeeze m
I’ve spent the last couple weeks diving head first into the world of vim. At times I’ve felt like a complete badass zipping my way around the terminal, editing large chunks of code with ease, and other times… well not so much.
For those that can’t squeeze more than a couple paragraphs in their brains - don’t worry, I think I too fall in that category - here’s my summary.
Vim is great and I’m glad I’ve spent some time familiarising myself with it. I no longer feel like vim is always the backup option if no IDE is available. Vim is now my first option when doing quick edits. But. And it’s a big but. For my daily workflow vim is not the best choice. Most of the time I’m reading through code or browsing the web. These tasks I feel have been optimised to be used with a mouse or trackpad. At the end of the day switching context with the keyboard focused vim, and mouse focused almost everything else makes sticking to an IDE the more sensible option in general .
Why use Vim
Vim is everywhere. Todays cloud centric distributed ecosystem has vim installed on most machines. I can almost guarantee that if you open up your terminal right now and try vim filename
you’ll find yourself stuck in a vim editor. SSH/RSH into into any virtual machine or docker container you have running and you’ll probably see the same thing.
It’s pretty damn powerful too. Getting proficient with vims command mode - messing around with the various motions, operations and macros - at times can seem magical.
motions - movements around the text, such as w (word)
operations - the actions, such as d (delete)
macros - on the fly shortcuts, to replay the last command (.) or series of commands (q)
It’s ultra customisable. Don’t like the way your vim editor looks? Want better code completion? Want to add some new operations to your toolset? You have complete customisation by editing a few lines in your vimrc
file.
What I hoping for
Going in to this I knew you couldn’t become a vim wizard overnight. Two weeks of vimming later and I know this now more than ever.
Main main goal was to just test out the waters. I had no expectations so anything I took out of this would be a win. I knew I would take a productivity hit initially. But hopefully the few hours lost over two weeks would be worth it in the long run. Long story short. Yes it is absolutely worth it.
How I went about it
From the start I decided I was going 100% all in on Vim. If I was editing single files I did it straight from the terminal. Otherwise If I needed an IDE for switching files, intellisense or auto formatting I made sure to download a Vim extension. For IntelliJ I used IdeaVim and for VS Code - Vim - Visual Studio Marketplace .
I started my vim journey as probably most do - using vimtutor
. It’s essentially a tutorial document explaining everything you need to know to get started. It’s built into most OSs again, so no need to download anything. Just run vimtutor
in your terminal.
My next few days were spent vimming everywhere I could. Where necessary I would tweak my vimrc
file until I was happy with the look and feel. I decided to keep the power extension to a minimum as I wanted to first get a feel for raw vim.
In my spare time I would watch some Vim talks, just to get a taste of what was possible in the long run. Watching some expert vimmers always seemed to help when my vim motivation was waning.
The Results
The Good
Learning new things is always rewarding. This is particularly true in our fast moving industry. Worst case scenario is that I would sink a bit of time into learning vim, then realise it’s not for me and change back to a full IDE. Best case, I’d have a new favourite editor that I can use anywhere. Either way though I would have expanded my tool belt with a handy new tool. Not much of a price to pay for the potential gains.
Secondly, vim macros have changed the way I think when modifying code. Macros allow you to record a series of modifications to a line, and replay them on any number of lines above or below. Most of these macros can be replicated with multi-cursor - but there are definitely some cases where macros can achieve the same results with potentially less hassle. It’s interesting to see how having repayable operations changes the way you think when coding.
Getting more comfortable with vim has also had one surprising side effect. I’m now more inclined to do general modification directly from the terminal. Moving files, deleting folders, searching in folders for a specific file. Previously I’d rarely do this from the terminal, and often I’d need a quick google refresher since I’d forget most of the commands minutes after using them. Now that I’m not as uncomfortable with editing files in vim, I find myself managing files and folder structures from the terminal more often.
The Bad
In isolation, I can definitely see the argument that your average vimmer will outperform your average IDEr. Even in my couple weeks I could see some speed improvements when digging in to a single file and making changes to it. But here is where the problem lies, it’s surprisingly rare that I find myself editing only one file at a time.
Most of my time is spent flipping between multiple files, ctrl clicking into function calls, cutting code out of one file and pasting it into a new one. I feel this can be done much faster with an IDE. And with the trend of having smaller singular responsible code files I don’t see this changing anytime soon.
Another potential pro of vim is that it allows you to keep you hands on the keyboard full time. In theory, this sounds fantastic. But again, what am I doing most of the time? I’d say a majority of my day is spent on my browser. I also constantly find myself scrolling through code, reviewing or refactoring. These task have been designed and optimised for a scroll wheel (or trackpad) and cursor. Simply put sticking to a mouse just make sense for these task.
Summary
I won’t be sticking with vim as my main editor. Am I disappointed? Maybe slightly. The idea of a super customisable, powerful, lightweight editor I can use anywhere sounds great. But for my daily workflow, I find myself too reliant on an IDE with good refactoring tools. Global find and replace, or find all code references are very important to me - an IDE just seems the better tool for this specific job.
But that doesn’t mean I’m not glad to have tried it out. Multiple times a day I am making quick changes to a kubernetes manifest, or just updating a json key somewhere (local, or on a cluster). This is where vim shines. And at least now I’m not spending five minutes clicking the down arrow to find the line I want to edit. I can undoubtably say that having a basic grasp of vim will come in handy for the rest of my career.
That was two weeks well spent.
以上所述就是小编给大家介绍的《Should I use Vim full-time?》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!
猜你喜欢:本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
C语言接口与实现
(美)David R. Hanson / 人民邮电出版社 / 2010-8 / 79.00元
可重用的软件模块是构建大规模可靠应用程序的基石,创建可重用的软件模块是每个程序员和项目经理必须掌握的技能。C语言对创建可重用的API提供的语言和功能支持非常少,虽然C程序员写应用时都会用到API和库,但却很少有人去创建和发布新的能广泛应用的API。本书介绍用一种基于接口的设计方法创建可重用的API,这一方法将接口与实现分离开来,且与语言无关。书中详细描述了24个接口及其实现,便于读者深入了解此方法......一起来看看 《C语言接口与实现》 这本书的介绍吧!