Friday, October 18, 2013

ETB: Editing: Just 3 Shortcuts for Dramatic Efficiency Gain

Continuing on the Embracing The Beast (ETB) series, this time we're going to dive into the text editor.

If you edit at all like I used to, these 3 shortcut keys will save you a huge number of redundant keystrokes every single day.  Yep, just learning 3 new shortcut keys.

I'm not going to keep you waiting, here they are:
Shortcut Action
Ctrl+L Cut current line
Ctrl+C (with NOTHING selected) Copy current line
Ctrl+Enter Insert blank line above

I have learned tons of new shortcut keys since I started this process, but these three are the most important.  If you learn this and nothing else in this series, it will still be a marked improvement!

Why?  Let's take a look.

Cut Current Line
Like it says, this command cuts whatever line the cursor is on (meaning it copies it and deletes the line, including the carriage return).  You can use this to easily move a line up or down, or to just delete a line.  There is a command that deletes the line without cutting it (Shift+Del), but when you're just starting out it pays to limit the number of things you're learning all at once.  Ctrl+L does the same thing that Shift+Del does, and rarely will the difference ever bite you.  Start simple.

"Cool man, but like, why is this such an efficiency improving short cut?"

Glad you asked!  Here's the sequence of keys I used to hit to do the same thing Ctrl+L does in one keystroke:
  1. End
  2. Shift+Up
  3. Ctrl+X
3 keystrokes when I could have used 1!  Suppose you delete or move lines 100 times a day, which is probably crazy low.  You would save 200 keystrokes.  This paragraph is only 195 characters long.

Maybe that doesn't seem like a lot, but there is a hidden benefit here too; Ctrl+L is a single command that maps directly to a pretty high level action you wanted to take.  It may be only 2 keystrokes better than the more manual way, but you don't have to busy yourself thinking about the micro steps required to move the cursor and highlight text.  You just, BAM, do the action you want.  End. Of. Story.  Conceptual overhead here is much reduced!  

Copy Current Line
I used to do this the same as above, except I'd Ctrl+C instead of Ctrl+X.  But it turns out, if you just hit Ctrl+C when nothing is selected, VS will copy the entire line!  Brilliant!  

Suppose I copy half as many lines as I delete: 50/day =100 keys saved. This paragraph is 98 chars.

Add Blank Line Above
You might not think that you do this operation too often, but I think you'll be surprised.  How many times do you write a block surrounded by {}?  There are LOTS of ways you might do this, but the way I usually do it is I write the definition, the open {, and then the closing }, and now I want to go back up and type in the body, but I'm stuck below it!

Here's what I do:
  1. Up
  2. End
  3. Enter
That's 3 keystrokes again instead of just Ctrl+Enter!  Interestingly, this is the one I'm having the hardest time training myself to take advantage of.  That could be because how often I use it varies depending on what I'm coding, but I bet on a typical day I do this way more than I copy lines.  Lets go with 200 times a day, for 400 keys saved.  And you guessed it, this paragraph is 396 chars.

So with all three of these combined, and given my completely made up numbers, that's 700 keystrokes saved, every day, just by using these three shortcut keys,  That's clearly a good thing, but the real benefit is in the fact that you're now communicating with your editor on a higher level than just cursor up and down.

Monday, October 14, 2013

Embracing The Beast: Navigate To

Next up in the Embracing The Beast series is Navigate To.

The Navigate To feature introduced in Visual Studio 2010 is the single most important feature they added that made it possible for me to work in Visual Studio without proclaiming my longing and desire for Vim at the top of my lungs every 5 minutes.

The shortcut is Ctrl+, (Control Comma).  But the shortcut is just the beginning of effectively using this thing.

What it searches
Files, types, members, and variables.

Search string formats
An all lower case search basically does a case-insensitive "contains" search, but it intelligently sorts the results preferring "Starts With" over "Contains".  For example, if you search for "ext", you'll find things like Properties named "Extension" or Methods named "Extract" before you'll find Properties named "Text".

But change your search string so that's it's not all lower case, "Ext", and now it does a case sensitive search which would still return "Extension" and "Extract" but not "Text".

Make your search string all upper case, and now it does a PascalCaseAware search!  For example, search for "AVE" and it will match AbstractValidatorExtensions because of the PascalCase, and "AutoSave" because of the case insensitive contains match of "ave" in "Save".  Unfortunately it returns the contains matches before the pascal case matches, so this can require a lot of pascal case characters before it will return the item you want at the top.

Put spaces between search terms and it basically does an "and" search, but it's position independent.  "auto save" will of course match "AutoSave", but so will "save auto"!  Lest I mislead you, the matches don't have to be adjacent, "location incident" will match "AddLocationToSomeIncident".

Tips
Suppose you are looking for a file, and you know part of its name and you know its a JavaScript file.  Search for "partofname .js".  The ".js" will bring .js files to the top of the results.

Suppose you're looking for the Index view of an MVC controller.  There are lots of Index views in your website I bet, so searching for just "index" isn't going to get you too far.  Try this: "views partofcontrollername index".  partofcontrollername just has to be a unique enough subset of the name of the controller to bring that folder to the top.  This illustrates that Navigate To isn't just searching the file name, but the entire file path!

If you have more Navigate To tips, I want to hear them!  Comment below or twitter at me!

Tuesday, October 8, 2013

Embracing The Beast: Where Do We Start?

The Beast, as explained in the first post, is Visual Studio, and my objective is to finally really master it once and for all.  What's the criteria for "master"?  It's not a simple question because VS has so many different parts and features...  Does mastering it mean you know when and how to use every single one of those features?  Does mastering it mean you use it as fast and efficiently as possible?  Where's a poor vim-loving-wanna-be-hippie-alt-dot-net-developer to start?

There's two main related places I believe make the most sense to start, and that I believe will help drive out learning what other bells and whistles and sirens and synthesizers VS has to offer:
  1. Let go of the mouse
  2. Touch fewer keys
That's it.  Just those two things should give us a really solid start at becoming much faster and more efficient when coding in VS.

I'm guessing I don't really have to convince most of the people reading this that this is correct.  But, you know, it's low hanging fruit, so I'm going for it anyway...  Maybe you like the mouse.  Maybe you read that one ancient article from the early Mac days that says using the mouse is actually more efficient than the keyboard.  OK.  Tell me, how often do you save the file you are editing by:
  1. Grabing the mouse
  2. Dragging waaaaaaaaaaaaaaaaaaaaaaay over (monitors are BIG these days) to the File menu, clicking it
  3. Dragging down to the save item, clicking it
Or do you just hit Ctrl+S like 100,000 times subconsciously every time you stop to think about what to do next?

I thought so.

That's the thing about keyboard shortcuts, once you have practiced them to the point where they are engrained in your muscle memory, they are fast and require no thought and no time lag, allowing you to forget the physical steps of editing and focus on the more abstract ideas of what you are editing.  But lets not skim over the most important part of that last sentence: practice!  Real practice.  The kind of practice familiar to most people who have played a musical instrument of some kind, which mainly consists of repetition, repetition, repeating yourself, doing it again, and again, repetition, slow repetition, fast repetition, and then more repetition.  And if you didn't study music but instead spent your time going to sporting rehearsals (is that what they're called?), you probably experienced much the same thing.

So, if we are going to let go of the mouse, and touch fewer keys, we're going to have to practice shortcut keys.  For me that practice usually looks like:
  1. Learning a new shortcut key
  2. Writing it down
  3. Trying it out a few times
  4. Purposefully finding opportunities to use it
  5. Paying close attention to my coding and if I miss a chance to use it,
  6. leaning on undo
  7. doing it again with the shortcut
Repeat, repeat, repeat, repeat, repeat.  It's also important not to stretch yourself too thin all at once.  Focus on a couple things at a time, work 'em to death, then do some other things, then go back to the first things again, etc.  Some of this is going to be extra-curricular.  Some of it can happen on the job.  Some of it will slow you down a bit.  It's OK, you're going to be happier for it soon.  And it's not going to take as long as it feels like it does.  I have no studies to prove this, I believe it on blind faith alone, and encourage you to take my word for it.  We're software developers after all and that's how we do this.

OK, cool.  So we need some shortcut keys to learn.

The Basics
These are the essentials, chances are anyone who's used VS for any amount of time knows these already, so let's get them out of the way.

ShortcutAction
F6 or Ctrl+Shift+B Build
Ctrl+F4 Close Window
Ctrl+, Navigate to
F5 Run
F9 Toggle Breakpoint
F10 Debugger Step Over
F11 Debugger Step Into
Ctrl+R, T Run Tests
These you already know cut, copy, paste, undo, redo, save

Slightly Better Than Basic
Moving a tiny bit up the scale toward shortcuts that are still bread and butter, but might be slightly less well known.

ShortcutAction
Shift+F5 Stop Debugging
Ctrl+E, C Comment Selection
Ctrl+E, U Uncomment Selection
Ctrl+M, M Toggle Outlining
Ctrl+M, L Toggle All Outlining
Ctrl+G Go to Line
Shift+F6 Build Current Project Only

Learning shortcut keys isn't all there is to mastering an editor, but it's a big part, and it's certainly the first step.  With these basics out of the way, we can move on to more interesting stuff.

Friday, October 4, 2013

Embracing The Beast

The year was 2001, the language was VB, the editor was Visual Studio 6.  It was the first time I used Visual Studio and, to be honest, I didn't give it any thought.  Before that, I'd been developing in Turbo C and Brief.  I really liked the Brief editor.  It helped that my dad loved it and knew it pretty well too.  In any case, it was the first editor I ever took the time to learn.

Like your first language, your first editor molds your expectations.  Brief was a keyboard driven, light weight, text focused editor.  It was brief.  And it had really really good (and brief) help.  I no longer remember any of it's shortcut keys or even much about it's interface, but I still remember spending hours navigating through it's help like it was Wikipedia, "oh that sounds interesting." *click* "huh, what's that?" *click* "oooh!  that sounds cool!" *click*.

But I was working and schooling in the land of the beast now, so no more Brief.  And compared to Brief, Visual Studio is a BEAST!  Slow, mouse oriented, cluttered with tool windows sliding in and out from every direction, toolbars everywhere with countless incomprehensible icons.  And no help.

I think I did C++ in VS for a full year before I learned about the debugger, arguably VS's killer feature.  Isn't the whole point of all this UI mouse driven stuff to make it more discoverable?  It didn't work for me.  It wasn't my expectation from my Brief days and with the really bad help, I had no way to learn it on my own.  I finally learned it from one of my classmates, watching over their shoulder as they tried to fix a bug.  My life changed that day: no more print statement debugging!

I learned a lot of Visual Studio after that, but I never liked it, and I never found a good resource to help me learn more about it.  I didn't feel bad about it, cause VS was still a slow, ugly, bloated beast.  And, I seriously hated it so much I invested ALOT of time configuring Vim to do C# development completely outside of VS.

But that began to change about 3 years ago with VS 2010.  It got faster and more usable in some key ways (though slower in others), and suddenly I found myself spending less time in Vim and more time in VS.  It also helped that I was doing more web development than winforms or wpf development.  Then with VS 2012, it got dramatically better still.  I installed VsVim and hardly switched into Vim at all anymore.

It took awhile before I realized I really didn't hate Visual Studio anymore.  And awhile longer after that before I realized, "Hey, I bet if I studied this thing the way I studied Vim back in the day, I could wring a lot of performance out of it".  So I started paying attention to how I was using it, and I started researching VS tips, VS shortcuts, VS productivity.  I haven't found one single good resource, but there's plenty of random blogs with scattered tips.

Then this week, I took a big step.  I turned off VsVim.  **gasp!**

So far, it's been a surprisingly good experience.  Better than I was hoping.  I'd like to write up some of what I'm learning here, much like the Vim series.  But I'm still working on ideas of how to present it.  It's harder than with Vim, VS being such a beast and all...