Visual Studio Code: A first time user’s review

(One week earlier in a hotel room.
It’s late dusk and the street lights
are on in the parking lot outside.
The protagonist sits at small wooden table;
the kind of small wooden table a person
finds in a hotel room at late dusk.
A laptop on the table is open and
the screen flickers with many open
gVim windows, each showing a different
piece of code.)

I need a better way to manage writing my code.  There’s just too many windows open. Whenever I need to switch to a different window I have to ALT+TAB thru five or ten windows I might not even be using any more just to get to the window I do want.

Aren’t you writing C# code?  Why don’t you just use Visual Studio?  It has built-in tabs, code snippets, Intellisense, refactoring, automatic code generation, and the list goes on.

Yes, I’m writing in C#.  I’m also writing Python, Javascript, HTML, JQuery, CSS, and T-SQL.  And maybe some day I’d like to write Java, Elm, Clojure, Go, Swift, WebAssembly, Scheme, or who-knows-what.  And maybe I’d like to compile my code with Make, or some other tool of my choosing, and not MSBuild.  Besides, you’re right; Visual Studio does a lot for you automagically and behind the scenes.  Haven’t you ever wondered what, exactly, it is Visual Studio does and whether it can be done without it?

Not really.  But if you’re looking for a different experience that isn’t so closely tied to Visual Studio and Windows you could try a text editor built using the Electron framework.  Just searching Electron’s Apps page for ‘code editor’ reveals these three: Visual Studio Code, Light Table, and TweakStyle.

Hmmm.  I don’t anything about any of these, so I guess I’ll pick one to start and work my way through the list.

(One week after one week earlier in a house.
It’s late evening and somewhere the street
lights are on. The protagonist sits at a
large wooden table; the kind of large
wooden table a person finds in a house
late in the evening. A laptop on the
table is open and the screen flickers
with an open Chrome browser window,
showing a blog post being written.)

You’ve been working with Visual Studio Code this week.  Maybe you should record some of your initial thoughts so you don’t lose them.

Good idea.  Overall, I’ve had a very good experience with Visual Studio Code.  I started setting up my environment by downloading a few extensions:Vim by vscodevim, C# by Microsoft, and Python by Don Jaymanne.  I like that Visual Studio Code has its own marketplace for downloading extensions, and provides guidelines and tutorials for building extensions.

This isn’t a post reviewing the extensions themselves, but Visual Studio Code’s true strength is in the extensions, so it’s only fair to say a few words about the ones I used:

  • Vim by vscodevim did everything I hoped.  One thing to be aware of is that certain Ctrl combination commands (like Ctrl + N to open a new tab) will be overridden by default.  However, this is easy to find and disable in the settings if it’s a problem.  I really didn’t find it to be a problem since I could use Alt+F, N to do the same thing through the file menu.
  • C# by Microsoft works pretty well.  I’m using 1.10.0, which is a preview.  I haven’t had a chance to explore its full power since I’m not using a csproj or settings.json file and I think a lot of the services like Intellisense and find definition need this. The syntax highlighting seems to work well for the most part, but I have one or two lines of code where it’s not right.  But again, the version I’m using is preview.
  • Python by Don Jaymanne worked well.  The intellisense was nice, and I didn’t have any issues with the syntax highlighting.

Very nice.  What about Visual Studio Code itself?

Right.  So, now that I had Vim keybindings and the syntax highlighting I like, I found adjusting the following built-in settings pretty much finished the setup I needed to get my editor where I like it:

  • editor.insertSpaces
  • editor.wordWrapColumn
  • editor.renderWhitespace
  • editor.rulers
  • workbench.editor.enablePreviewFromQuickOpen
  • workbench.editor.enablePreview

Wait, so those are the only built-in settings you needed to adjust?  That’s pretty easy.  What do the last 2 do?

I was having trouble opening files in new tabs.  When I tried highlighting a file in the Visual Studio Code file explorer it would open the file in the same tab that I had active at that time. Whereas, I wanted each file to open in its own tab.  So, setting those last 2 to false enabled the new tab behavior I wanted.

I see.  So how did Visual Studio Code improve your development experience over the past week?

Well, I’m working with a directory tree that is several layers deep and has html, cs, py, js, and sql files.  Before trying Visual Studio Code I was using gVim.  When I needed to open a new file I had to stop what I was doing and either go to the file explorer (or command line if I knew what directory the file was in) and slowly navigate through the directories until I could find and open the file.  With Visual Studio Code I was able to open the top level directory in the Visual Studio Code file explorer by going to File -> Open Folder and then navigating to the top level directory.  From then on, whenever I needed to open a new file I used Ctrl+Shift+O to open a search bar over my tabs.  I then backspaced to remove the ‘@’ symbol, because the search bar always comes pre-populated with an ‘@’ symbol that I don’t yet know how to get rid of, and then I started typing the name of the file I wanted to open.  As I typed, the drop down box would start populating with matching file names found from within all of the directories at and below the top level directory open in the Visual Studio Code file explorer.  Then I would just hit enter when the drop down list showed my file as the selected choice.  Boom! Done.

So that probably saved you 5 to 15 seconds each time you needed to open a file.

And it kept all of my open files in one place.  Instead of having to to ALT+TAB through every open app on my computer I was able to CTRL+TAB through just the open files I was working on and I only used ALT+TAB when I needed to change apps.

Which still probably happened pretty often, right?

Actually, not as often as you’d think.  Hitting CTRL+` in Visual Studio Code toggles a window with a terminal.  From there, I was able to just type csi to enter the C# REPL, or ipy64 to enter the Iron Python REPL, or svn for any of my source control commands, or make for any of my build commands.  The only time I found myself changing apps was to go to my browser or run unit tests.  And the unit tests could’ve been run from the Visual Studio Code terminal as well, but I like to have a more maximized window for that.

So, Visual Studio Code comes with a built-in C# REPL, Iron Python REPL, Subversion, and Make?

Well, no, not that I know of.  I still had to add those programs to my path to get them to work.  You can see my previous post to find the C# REPL exe so that you can add it to your path.  As for the others, see their respective documentations.

So, to summarize, Visual Studio Code enabled you to find, open, and switch between files more quickly, use the Vim keybindings that you know and love, and execute most of your command line tasks without your hands ever leaving the keyboard.  That sounds pretty productive.


Author: adam_stidham

Hmmm... maybe I should put something deep and riveting here?

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s