Sublime is Sublime Part 1

This is the first blog post in a series about getting sublime working for .NET development. We will look at how to get nice color schems, git integration, command line integration, handling project and solution files, and both manually and automatically building/running unit tests. Before getting into the details about how to get everything setup one of the most important questions that should be looked at is *why*.

Why not just use Visual Studio and Resharper? Are you just some kind of hipster?

And the chap below is not really a hipster. 


I was for a long time a fan of VS+R#. It is quite a nice IDE. Over time however I started seeing some of the downsides of this particular setup.

The first is that its a windows/microsoft only experience. Currently the majority of my machines do not have windows installed on them. They are running linux. I am not saying that windows is a bad platform but to have my dev tools not work in linux is for me a downside to the tool.

VS + R# is also an extremely heavy tool chain. It is common for devs to need i7s+16gb of ram to be effective using the tool chain. This is especially true for those doing things like solution wide analysis with R#. I have never met a developer in VS who has not had the “I just want to open a file what are you doing!” moment while VS somehow takes 20 seconds to open a text file where a normal text editor should be able to do this in under 500ms.

Another advantage to not using VS is that the tooling can be used for other things. How many keystrokes have you memorized in Visual Studio? How applicable is that knowledge to working in erlang. Lately I have been writing a lot of code in erlang and in C. One positive aspect of just using a text editor is that my tooling is portable to multiple environments/languages. How many companies do you know that have programs to try to learn shortcut keys in their editor du jour? Is that knowledge portable?

There is also an issue of cost. We in the western world often forget how much things really cost from a global perspective. My entire investment on my tooling was $70 for a sublime text license though you can use sublime for free if you want on an “evaluation” period. It will annoy you occasionally about licensing but will still work (I was actually using it this way even though I had a license just because I wasn’t thinking to put my license in). $70 will get you roughly 1/3 of the way to a resharper license (with paid upgrades roughly once per year) forget about tooling like Visual Studio Ultimate at $13k. I could have a team of twenty for roughly the same cost as one developer.

But won’t I miss Resharper and all the great things it does?

Yes. You will. Resharper has some great functionality and when I use it I really feel like I am coding significantly faster. Sublime will not optimize using statements for you. Sublime will not see a type and offer to add a reference for you. Sublime does not have intellisense (although this can be reasonably easily built into it). Sublime does not have automatic refactorings. I would however challenge you to still try using it.

A while ago (roughly two years ago) I decided to actually measure my usage of resharper and how much faster it made me. To measure I wrote a program that would track keystrokes going to Visual Studio (obviously resharper won’t be helping me in chrome). I then put a hot key to track when I was starting to code and stopping. In measuring resharper did make me much faster in the process of inputting or changing code the problem was evev during code heavy times this was a rather small percentage of my overall work. A lot of time was being spent thinking about the code I was writing and/or researching about the code I was writing. I found it to be for me a micro-optimization (try measuring, your results may be different).

There are also downsides to tools such as resharper. One I noticed was that I had basically forgotten which namespaces things live in as the tool would automatically add references for me. Resharper also does some things that you would never do yourself. As an example in a rename that affects domain objects, dtos, and your client. In doing such a “refactor” you also just broke your wire protocol without realizing it. On many teams I would see developers commonly checking in 70+ files why? They were renaming things. Renames that bubble out this much are generally a sign of a problem.

Said simply resharper can help hide many design problems in your code especially problems with encapsulation. Being forced to type your code in will often times also lead to better ways of doing things. I gave an example of this in my 8 lines of code talk when dealing with an application service.

public class InventoryItemDeactivationService {
 private IInventoryItemRepository _repository;
 private IDriversLicenseLookupService _driversLicenseLookupService;

public InventoryItemDeactivationService(IInventoryItemRepository repository, IDriversLicenseLookupService driversLicenseLookupService) {
 _repository = repository;
 _driversLicenseLookupService = driversLicenseLookupService;

public void DeactivateInventoryItem(Deactivate d) {
 var item = _repository.GetById(;
 item.Deactivate(d.reason, _driversLicenseLookupService);

compared a more functional approach of

public static void DeactivateInventoryItem(IInventoryItemRepository repository, IDriversLicenseLookupService driversLicenseLookupService, Deactivate d) {
 var item = _repository.GetById(;
 item.Deactivate(d.reason, _driversLicenseLookupService);
 var handler = x => Deactivate(new OracleRepository(), new CALookup(), x)

In the top piece of code a tool like resharper will help me greatly because everything I am doing I have to type three times. In the second example though I get much less help from my tooling as I am not repeating myself. I would suggest that if you are actually typing your code by hand you are less likely to use the first style and more likely to be interested in the second.

I also find people who are doing TDD in static languages with such tooling to not understand what the concept of a refactor is compared to a refuctor where as dynamic language people working in plain text editors do. A refactor is when you either change your code but not your tests or your tests but not your code. One side stays stable and you predict what will happen (one side stays as your pivot point). If you change both your code and your tests concurrently you no longer have a stable point to measure from. With this tooling often forces changes to happen on both sides and it is no longer “refactors” that people are doing.

In summary

I am not in any way saying that VS and R# are bad tools I have found both to be quite effective. I am simply suggesting that they have their downsides like any other tool. Being able to develop in a plain text editor is a wonderful development environment and has some advantages to larger tooling in some cases.

In this series we will look at how to get everything setup to have a reasonable code editing experience. We will look at integration of tools such as git. We will look at how to manage many of your day to day tasks. We will not get into things like how to edit a winform with a WYSIWYG editor as frankly you can’t do this.

This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

11 Responses to Sublime is Sublime Part 1

  1. gregyoung says:

    Thats what the post set is covering.

    By the end we have auto running tests, intellisense, some basic refactorings, prj/sln support, things like to goto definition.

  2. Josh Kodroff says:

    Sorry, Greg. I’m not really feeling you on this one. Of course, I’m not the one working in Linux most of the time…

    I *do* use Sublime for my non-C# work and I think it’s a great editor, but I feel like you’re trying to fit a square peg into a round hole here. To me, tools like Sublime are awesome… if you’re not working in a statically typed language. What tools are the Java community using? I’m guessing they use IDEs just like the C# devs do.

    But I don’t think the tooling is really the issue. I think, like you said above, that the problem is it’s Windows-only and expensive relative to the common dynamic language toolsets. For my complaint on the cost of Windows dev, you can check out my blog article. I also have to flag you for a straw man argument for citing the cost of VS Ultimate. No human being needs it and I’m sure you know that. VS Professional is $500 and all anyone ever really needs.

    What I think would be awesome would be an open source effort at getting the best functionality of R# and VS into some sort of modular plugin framework so that it could be done independent of keystroke, text editor, and OS. Now *that’s* an open source project I would jump on. Is anyone doing it?

  3. gregyoung says:

    Also yesterday was a classic example of the problems I have. Visual Studio open->git pull in command shell. Oops files are locked by VS

  4. gregyoung says:

    There are some things I can’t do in sublime well. A big one is large namespace refactorings in which case I will bring out another tool like R#. For day to day stuff I find I am actually faster in sublime.

    One interesting bit that I made the point of here but not strongly enough is that often codebases written using tools require such tools to work in them efficiently. Dependency messes are a good example of this and I am currently cleaning one up that I do not believe would have been created without the use of such tools as its really painful to work with without them.

  5. Evade says:

    Further to my previous posts:

    Visual Studio 2012 + Resharper takes 45 seconds to open on my Core2Duo/4GB laptop. I just timed this and, I admit, this is slow!
    However, I experienced no lock ups over a whole day of usage as you have described… maybe I’m lucky

    I have seen really large solutions in Visual Studio. It doesn’t cope well. I’ve seen solutions with over 100 projects (this is insane and Sublime is not a solution to this insanity)

  6. Evade says:

    gregyoung, what you’ve fallen victim to is called confirmation bias.

    I have tried other tools including Sublime. I use Notepad++ if I want to open something quickly (probably on a daily basis), this supports many languages too.
    I’m also a big fan of other JetBrains tools like, IntelliJ IDEA and PyCharm.
    I’m not criticizing Sublime for what it is. It may be able to do >90% of what you spend your time on – but it simply can’t do the rest.

    For an example, have you ever read, “Working effectively with Legacy Code”, specifically, the “Legacy Code Dilemma”? Tools like Resharper enable you to more easily bring code under test that you wouldn’t be able to do with the same speed or confidence.

    I made sure I counted the >5s lock ups or long unit tests runs for a whole day. Guess how many? zero. Although I will admit VS takes an age to load up! Although, that isn’t very relevant as, I didn’t actually restart Visual Studio. Have you actually done a whole day coding in Visual Studio 2012 or 2013? It could be a 2010 legacy as that had some more lockups.

  7. gregyoung says:

    Of course this is said without ever actually trying the other side. What are the problems VS and R# solve well that aren’t solved well outside?

    How heavy is r#/vs? How many times per day does it just lock up for 15-30 seconds? Why does it at times take 15-30 seconds to run a single unit test? There are definite downsides to the massive tooling chain.

    I actually find I am now just as fast overall using either tool. In fact much of the tooling outside of VS is far superior to the VS tooling. Emmet would be a perfect example of this (formerly known as zencoding)

    By the end of the series we will also have fully automated build/minimized test runs as well as further tooling which simply doesn’t exist in VS. That said there are some things VS does really well. Debugging, code profiling, loading up unmanaged dumps. Its worth keeping a copy around for these things.

    The fact that my tooling also works in basically any other language is just a bonus. Not having to spend 3-6 months relearning a heavy tool chain because I want to be working in erlang is nice.

  8. Evade says:

    This is one of the most retarded things I’ve read this year. Next, you’ll be debating Vi vs Emacs.
    Resharper is a great tools that enables a bunch of things that wouldn’t be possible otherwise.

    I have a toolbox. I don’t like carrying it round with me everywhere because its too heavy. I keep hitting myself on my thumb with my hammer. From now on, I’m only going to use a screwdriver.

  9. Mike Ward says:

    You can have my R# when you pry it from my cold dead IDE :)

  10. gregyoung says:

    Tools like sublime have things like class/filename completion in search windows.

    That said find usages is quite useful. Its something I miss when working in code that is new

  11. zok says:

    While the ninja tricks videos are entertaining, one of the main advantages of R# is actually not typing speed enhancements.I can easily imagine master of Vim or Emacs equipped with handy macros beating R# editing speed, but as you said yourself, most of the time developer spends on the code is looking at it and thinking. And that’s where R# analysis shines – it really aids you you see your code as an interconnected entity and easily jump from one piece of connected logic to another and back while thinking. Especially when you are getting used to existing codebases you inherit, it is vital to see what piece of code references what, what inherits what, class/file name completion in the search window, all that fun. <3 R#

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>