As stated
on my about page, I work as .NET developer in a company producing business
software. I believe a traditional C# developer spends most of their time in a
feature-rich IDE, which is Microsoft Visual Studio in most cases. However,
during recent months I’ve been seeing myself gradually moving some of my
activities to the command line, where in fact I can achieve a great deal of my
goals at much lower cost than in a modern IDE.
My first
conscious moves toward command line took place more than a year ago when I did
Java development on my previous job. Like the .NET world has its most popular
IDE, Java world has its own guys – for instance, Eclipse. Due to the simplicity of things that I
built back then I haven’t faced most of the problems, which Eclipse-based
developers lament about, though at some point it turned out that I actually
want my job to be done a bit faster and a little different than the IDE allowed
to. My primary concern was the need to quickly package a couple of JARs, obfuscate them and put the result
into an appropriate place. It was easy to achieve something like this through
doing all three steps separately: open project in Eclipse and assemble a JAR, launch obfuscator tool and feed the
archive to it, put the result wherever it has to go – nothing complex. On
the other hand, both launching Eclipse and the obfuscator took some time, with
the additional seconds being spent on surfing through the Eclipse menus as well
as locating the desired configuration files for the obfuscator, so after
running the scenario several times manually I had no choice except for forming
a strong desire to automate it. Because I also wanted to understand what
Eclipse does under the hood when I ask it to compile the project I got some ant manuals and started automating everything away. In a couple of days I had
what I wanted: I could open Powershell, type in ant ship and it would quickly
do all the above steps on its own, so that I have only to decide what should be
done with the obfuscated JARs. The
economy of time that it awarded amazed me so strong, that I even went further
and included into the build-file such targets as test and testncommit so
that I could not only run tests from the shell, but also check changes into
Mercurial in case the tests pass – sort of continuous integration on a single-man project. What made me stick with the command line then was the fact that it
could save me from navigating through multiple IDE’s windows in addition to
merely running things a bit faster.
Next time I
searched for help from the shell during the work on my diploma project. At
some stage of a major refactoring I still had a dozen or so very long and slow
tests for fat components, which I was going to replace later. Since these classes
were not touched during the most days until the time has come to deal with
them, there was no reason to waste time on their tests during each run.
However, it turned out that one cannot simply ask Visual
Studio 2012 tests runner to ignore a couple of TestClasses or TestMethods. In addition to
this, the IDE didn’t always successfully discover all the tests upon
rebuilding. These little issues made me search for better options and thus find
the vstest.console.exe tool, which simply runs the tests from command line. Not
surprisingly, it allows to filter the tests being run, for example, by test
classes names – that was precisely what I wanted at that moment. A
nice thing to mention is that while the command required to run vstest utility
with certain tests library and filters is quite long and awkward, most shells,
including the PowerShell, allow one to set up different aliases to save some
typing, so running tests becomes easier and faster than from the IDE – in
addition to providing broader functionality.
Maybe the
strongest push in the direction of command line I got from Visual Studio 2012
for C++, when I was experimenting with Cinder graphics library. Here the
blocker was the environment’s speed: VS did everything deadly slow – sometimes
so slow, that it was literally impossible to put in a line of code. I spent
some time on tuning precompiled headers, which helped with compile time and
even seemed to improve the situation in editor, still the state of affairs remained
awful. What made me finally close Visual Studio and turn to compiling like
msbuild.exe MyProject.vcxproj was the fact that in an attempt to increase the
speed of IDE and fight the horrible lags I had turned off IntelliSense. While
it didn’t help much with the original goal it made me ask myself why do I want
to stick with the environment if I get no assistance from it? With quite modest support
of C++ in the IDE part of Visual Studio (or without it after disabling
IntelliSense) I merely could not find a reason to stay in the slow environment
when I could switch to the Sublime + PowerShell combination boosting things
considerably. I acknowledge that my Acer Aspire P3 slate with i5
processor is not a powerful machine, while C++ is more difficult to handle than,
say, C# with which I did not face such awful quirks – I
can even assume that it would be faster should I use a Professional version of
Visual Studio instead of the Express one. Nevertheless, I can’t believe that it
is so bad that not being able to enter a line of code in the editor for 5
minutes (let alone the timeframes when it builds the project) is considered OK.
On the other side, once you turn to the shell, you are able to get binaries in
a matter of several seconds after typing in the msbuild.exe MyProject.vcxproj command. In case you change the contents of the precompiled headers, you’ll
have to wait a bit more, but at the same time you are not blocked by the build
process and it won’t prevent you from looking through your files or switching to
the browser. In contrast, if you build from Visual Studio, the only option you have is
to get some coffee and take a walk, because it somehow manages to slow down the
entire system significantly. This is another crucial characteristic of the command
line tools – they tend to do precisely what you ask for, while the complex and
shiny IDEs in their pursuit for the users’ satisfaction seem to be doing lots of
stuff behind the curtains even when you don’t ask for it. Furthermore, since
IDE has this beautiful and handy user interface, it also has a great option of
doing some hard work on the UI thread, thus making user face unresponsive
windows and feel frustrated, because their own tool stands in their way to
getting the job done.
Another
area where I quite often use shell-based tools instead of IDE functionality is
talking to TFS. One particular example is checking out a file for edit. When
the desired file belongs to a solution you work on, the task is pretty easy to
accomplish in Visual Studio – you just locate it in the Solution Explorer and chose check out in its context menu. The situation, however, gets a bit worse if
you want to edit a file, which is not included into any solution at all – just
a file in the repository. In this case you have to open the Source Control
Explorer thing, navigate it to the desired file (as far as I remember, unlike
Solution Explorer it has no handy Search function) and check it out through the
context menu – that is in fact a bit too slow because you have to switch to a certain
window and do some folders joggling there. Does command line have something on
offer to make the process easier? If you are used to navigating the folder
trees like ‘first 2 letters of the desired folder – TAB, … ‘ then absolutely
yes, because all you have to do to check-out a file through the command line is
type tf checkout path/to/your/file.extension. Although, this is not that
significant problem of the IDE and, in fact, I can hardly imagine the way it
could have been done better, there are other tasks where Visual Studio clearly
sucks in terms of working with version control – most notably, merging.
Since we
support several versions of our product, merge is frequently used on a
changeset basis, where you fixed a bug in one version and want to merge the fix
into another one. What you have to do to accomplish this in Visual Studio is going to cause some pain, because before letting you pick a changeset the IDE will
first ask the server for the entire list of those available for merging between the
selected branches (or locations inside them). Moreover, in my experience the
process of assembling this list sometimes takes up to a minute and in case there
exist broken changesets it may finish with a failure message not letting you
merge anything. Now, let me ask you a question: why would one want such a list
of merge candidates in case they’ve just checked-in the changeset, which they
want to merge and know its number? Why couldn’t there be a Merge button in
the Changeset Details window in Visual Studio? I don’t know the answer to the
second question, but I am pretty sure about the first one – I don’t need this
list at all, because I can go and type something like tf merge 4_10 5_00
/version:C159001~C159001 /recursive in the shell and it will instantly merge
the changeset 159001 from branch 4_10 to branch 5_00 if that is possible.
Certainly, this example does not serve to prove that command line is vastly
more powerful than IDEs – instead it just highlights the fact that there are
ways to go in making the developers’ tools better and sometimes one doesn’t have to
go very far to introduce a major improvement.
Overall, my
programming activities, even those started in powerful modern IDEs like
Microsoft Visual Studio, sooner or later led me to doing at least a portion of
work in command line. While there were always serious reasons for switching
from the fancy windows of the former to the awkward, 80s-style text-based
environment of the latter, I still don’t believe that this is a sentence to the
IDEs and their developers. Instead, I think programming environments are
just in the process of becoming better and easier to use tools and sometime
later, particularly when the human-computer interaction technologies will
afford that, IDEs will give developers as much power and freedom as shells do
for several decades already. Still, currently command line offers significant
advantages and here are just some of them:
- Shell is a lot faster;
- It’s more controllable and does precisely what you ask for, leaving out a lot of yak shaving;
- In some sense it is easier to navigate;
- Shell also serves as an entry point to a great deal of things, including your text editors, compilers, diff tools, revision control systems, testing frameworks and whatnot;
- It allows to set up and hold a piece of context through the use of aliases, functions and variables, which also means that shell is quite customizable;
- Command line keeps your fingers at the keyboard, which is especially important when coding – even the numerous hotkeys in an IDE can hardly compensate for this;
- And finally, yes, shell gives one a feeling of being a hacker in one of those legendary movies from 90s.
What makes
you trade a comfortable IDE for a good old command line? Are there any
particular tasks that you can’t accomplish in the modern environment, but which
are crazy simple to do in the shell? Or maybe you never had to leave the IDE
because it satisfies all your needs and never stands between you and your
goals? Please, share your opinion!
