Getting Started With Vim

2012-04-05T00:00:00-07:00

Learning to use Vim as your text editor is much like learning a new programming language, it’s going to be slow going at first but once you become proficient it’ll be a powerful addition to your coding tool belt.

Learning the basics

To keep things simple I’m not going to run you through the basics of installing Vim, for that you can check out the download and install instructions on the vim.org site. http://www.vim.org/download.php

Before jumping in the deep end I strongly suggest you learn the basics first by spending some time going through the Vim tutorial. To get started switch over to your command line and type in the following to fire up the Vim tutor.

vimtutor

That tutorial is going to take you around 30 minutes to work through and will stop you from throwing your computer out the window when you actually start editing text in Vim. Make sure you follow along and try out everything as you read through and remember to be patient as you progress.

After I had gone through the tutorial I would play around with Vim by editing single files for a while until I felt it was time to start using Vim for development work. One of the first features you’ll be wanting is syntax highlighting which is one of the many features managed in your .vimrc file.

Maintaining your .vimrc file

Your ~/.vimrc file is where you will store all of your customisations for your Vim development environment. If you trawl the internet you can find a wide range of example .vimrc files but I highly recommend you start with an extremely simple file that you slowly build up as you hit roadblocks or need to do something more efficiently. Something like this should get you started:

let mapleader = ","

syntax enable                   " syntax highlighting
filetype plugin indent on       " load file type plugins + indentation
set nocompatible                " choose no compatibility with legacy vi
set encoding=utf-8              " character encoding
set showcmd                     " display incomplete commands

"" Whitespace
set tabstop=2 shiftwidth=2      " a tab is two spaces (or set this to 4)
set expandtab                   " use spaces, not tabs (optional)
set backspace=indent,eol,start  " backspace through everything in insert mode

"" Searching
set hlsearch                    " highlight matches
set incsearch                   " incremental searching
set ignorecase                  " searches are case insensitive...
set smartcase                   " ... unless they contain at least one capital letter

To really get feel for Vim you should understand what each of those lines does and adjust them to suite your tastes. As you continue to use Vim your .vimrc will be changing fairly often especially in the beginning. I try to keep my file fairly small and maintainable and it’s currently around 100 lines with comments.

Working within a project

There are a few main players when it comes to moving around a project using Vim but for simplicity of use I recommend using CommandT. It can be a bit tricky to install and get running as it requires you have a version of Vim built with Ruby support but if you carefully read and follow the installation instructions you should be able to work it all out. Just remember to build the CommandT plugin using your system Ruby if you are using rvm to manage Ruby versions.

Once installed CommandT allows you to quickly jump to files in the same way you do when using TextMate, just remember if you are using command line Vim you may need to hit <Leader>t to use it instead of Command+T.

Getting ready for plugins

Now that you are hopefully comfortable editing files, customising your environment and working within a project let’s step into the world of Vim plugins. To do this I suggest you follow along this excellent article by Tammer Saleh that goes through each step you need to follow to set-up an easy to maintain plugin environment.

The Modern Vim Config with Pathogen

That article lists a lot of good plugins in the example code but as with your .vimrc file it’s important to understand what each plugin does and how to use it. Throwing other people’s plugins and configurations into your Vim environment without understanding what it does is a sure path to frustration.

Customising your environment

I like to have a gook looking and easy to read development environment. In the past it was difficult to make Vim look as slick as other editors such as TextMate. But with the correct font choice, theme colours and a couple of plugins Vim can look as good (or better) and any editor out there. Here is a screen shot of how my editor looks at the time of writing this article.

Everyone’s taste is going to vary a bit when it comes to the look of their environment so play around for a bit and see if you can find a look and feel that will work for you. Part of the fun with using Vim is customising everything so they look and work just the way you like them to.

Making the switch

There are a couple of different schools of thought when it comes to making the switch to Vim. There’s the cold turkey approach where you dive straight in and use Vim full time while you are learning it. There’s the gradual approach where you use Vim and occasionally switch to another editor if you need to do more complicated work.

Personally I went for a more gradual switch where I was using Vim at home for personal projects and then once I was happy with my efficiency I switched to using Vim for my contracting work. As with everything just play around until you find a system that suites you personally.

Lastly if you are interested in seeing how I have my Vim set-up have a look through my dot files on Github.

https://github.com/scottharvey/dotfiles

When Not To Test

2012-04-02T00:00:00-07:00

All code comes with a cost and your test suite is no different. Every line of code that you write needs to be maintained, reviewed and updated as your application evolves.

I’m a big fan of test first development but testing is a bit of an art form and part of the art is knowing when not to dogmatically follow the test first approach.

Quickly prototyping a new feature

When putting together a new feature I generally like to start by putting together the interface first. This will involve throwing together some HTML, CSS and possibly Javascript for basic interactions.

The code that gets written during this prototyping phase will rarely get put together using a test first approach because I’m just not sure what I’m building and in all likelihood it’s going to change once I get some feedback.

I also occasionally forgo the test first approach when building out a new class and I’m still uncertain as to how I want to interact with it or possibly still trying to determine how it’s going to fit into the system as whole. Once I gain more confidence in what I’m building I’ll often put the code to one side and then write it again starting with tests first.

Low risk code that doesn’t change often

Let’s say for example that I have an admin area where I can login and update a list of product categories. The code that powers this part of the system has been written hundreds of times before and this time around there’s nothing new being added.

If you are writing this with Rails and using Gems such as Formtastic and InheritedResources there is almost no code to write once you’ve setup your models, views and controllers. Considering this is a non-public facing area of the site, the code is not going to change much and it isn’t critical to the system I would be reluctant to test this much at all.

In the end I may just write a green path integration test just to make sure I can visit the page and fill in the form but anything more than that is going to be overkill and just more code to maintain in the future.

Hacking on code for fun

Outside of the scenarios listed above the only other time that I’m not testing is when I’M just hacking some code together to try out a new library, language or technique. This code more often than not gets deleted or thrown into a Git repository for future reference.

Overall you should be testing before writing code and you should be doing it often. Just remember that to every good rule there are good exceptions.

ScottHarvey.co