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.

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!

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.

Shortcut	Action
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.

Shortcut	Action
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.

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...

Powershell: Open Files Matching a Search

Have I ever mentioned how much I love Powershell?

What do you do when you want to search a bunch of source files for a given string, and then open all the files that matched your search?

First you have to be able to search a bunch of files, my earlier post Powershell Grep has you covered there.  This outputs objects (a MatchInfo if you want to know) that list the files and lines that matched.  If a file had multiple matching lines, it will be listed twice, so we need to do something about that.  Then we'll need to assemble all the file paths and pass it into our favorite editor (Vim, no surprise there).

In Powershell V3 syntax the command is:

gvim (grep SearchString | group-object Path).Name

In Powershell V2 syntax you have to use ForEach-Object:

gvim (grep SearchString | group-object Path | %{ $_.Name })

If you're a programmer, especially if you're a .NET programmer, powershell is just so wonderfully intuitive (even if it is a bit verbose)!

If you develop on the Windows platform and you haven't given Powershell a look yet, you really really should.  I learned it by reading Windows Powershell In Action, a book I really enjoyed for its brevity, good examples, and awesome asides about how and why certain design decisions were made in the language.

Powershell: testing string length validations

Every time I do this it makes me smile.

If you write apps that have input fields that have max lengths that are validated, then occasionally you may need to test your validations.  I used to do this by typing "this is a really really really long string that should break the validations" and the copying and pasting that over and over until I thought I'd gotten it long enough to exceed the max length.

Now I just switch over to powershell (which I always have conveniently open and ready) and I type:

"quite long" * 100 | clip.exe

"quite long" just happens to be exactly 10 characters long, so this generates a string which is 1000 characters long that looks like "quite longquite longquite long..."  Piping that string to clip.exe saves it on your clipboard. Now just paste into the field you want to test and you're all set!

Insight in Plastic Containers

Two simple small plastic containers.  The one on the left is a considerably better design:

• They nest inside each other because of the tapered shape
• The base of the container snaps into the top of the lid
• The lids snap into each other

I love examples of good design like this, but that's not why I took this picture!  

On the one on the left, see how the lid is facing down and the container fits on top of it, like this?

We have way more left-type containers and only a couple right-types.  The right-types don't fit into each other, and the lids don't snap on the bottom, so there isn't any great way to store them.  I usually just stuff 'em in the cabinet.  But today I opened the cabinet door and noticed the lid on the right-type as in the photo:

FLIPPED!  It's facing up instead of down, and the container nests relatively nicely inside it.  I couldn't help but smile at this!  

I have been fixated on the lids facing down because we have many more of the left-type containers, the idea of simply flipping the lid never occurred to me.  It's wonderful to reflect on the insight of just flipping the lid around.  A terribly simple idea that has been there all along, but I never saw it.  

An admittedly silly example of lateral thinking... Or maybe it's not really lateral thinking, maybe it's just closed mindedness through familiarity.  But in any case, when I saw it today it made me go "neat!"

POODR's Duck Types

I recently read Practical Object-Oriented Design in Ruby by Sandi Metz.  It's a really wonderful book.  I can say without any hesitation it has made me a much better Object-Oriented programmer.  I honestly wish I could have read this 12 years ago when I was first learning an Object-Oriented language.

Although the book is totally focused on Ruby, the OO practices it presents are easily applicable to other OO languages, including static languages like C#.  This makes it one of those timeless books you can be happy to have on your shelf knowing it's not going to be outdated in a year.  I highly recommend it!

I intend to write a few posts highlighting some of the good ideas that struck me the most from this book, but in this post I just can't help but take a few shots at it's treatment of static vs. dynamic languages.

My programming language lineage started by dabbling in C, then taking classes in C++, followed by Java, and finally C#.  Most of the real world code I've written has been in static languages, and I've been programming professionally in C# for the last 8 years.  This makes me a static language guy.

When I learned ruby, about 5 years ago, I fell in love with it's clean syntax and amazing flexibility.  I wrote a few simple tools in it for work, and I've written alot of rspec/capybara tests, plus I dabbled a bit with Rails.  I feel I have a decent understanding of the language, but I'm by no means an expert and I definitely still think in classes and types.

I tell you this to explain where I'm coming from.  Static languages are what I know best and are what I'm used to.  I'm not a dynamic language hater, I'm just comfortable with static langs.  Which brings us back to POODR.

POODR talks a lot of about "Duck Types" which are defined in the book as:

Duck types are public interfaces that are not tied to any specific class.  These across-class interfaces add enormous flexibility to your application by replacing costly dependencies on class with more forgiving dependencies on messages.

I was surprised at this definition because it describes the "Duck type" as being a thing, but in Ruby there is no thing that can represent this across-class-interface.  Most treatments of duck typing from Rubyists I've seen usually just talk about how it's a feature of the dynamic nature of the language.  They talk about "duck typing" but not "duck types."

In C# we have interfaces, which can be used as explicitly defined duck types.  The Dependency Inversion Principle and the Interface Segregation Principle are both trying to get you to use interfaces in this way, instead of just as Header Interfaces.  It's good OO because it focuses on messages instead of types.  As POODR says, "It's not what an object is that matters, it's what it does."

I think there is a lot of power in Ruby's implicit "duck types," but I also think the lack of explicit interfaces is a serious liability, and I was very entertained by how many hoops POODR jumps through to try to work around this problem, all while trying to claim that it isn't a problem at all, and in fact, it's great!

At the end of Chapter 5, there's a section that tries to convince you that Dynamic typing is better than Static typing.  Unfortunately, it just builds up a straw man version of static typing to make it easier to tear down.  What it leaves out is interfaces:

Duck typing provides a way out of this trap.  It removes the dependencies on class and thus avoids the subsequent type failures.  It reveals stable abstractions on which your code can safely depend.

If statics langs didn't have interfaces, this might be true.  But they do have interfaces!  And worse, interfaces represent a significantly more stable abstraction that is dramatically safter to depend on than these invisible "duck types."  POODR demonstrates this itself with examples where the "duck type" interface changes, but not all "implementers" of the interface are updated.  There's no compiler to catch this.  And standard TDD practices wont catch it either.  Your tests will be green even though the system doesn't work.  So you have to write manual tests that you can share across all the implementers to make sure the message names and parameters stay in sync.  Nearly all of Chapter 9 is devoted to testing practices that simply wouldn't be needed if there was even just a rudimentary compiler that could verify just inheritance and interface implementations.

The lack of explicit "duck types" just seems so problematic to me...  Keeping them in sync is a chore, and a potential source of error.  The worst kind of error too, because the same code may work in one context but break in another based on which "duck type" is used.

Another problem I've run into is when trying to understand some code that takes in a "duck type", how do you figure out the full story of what will happen?  How do you find all the implementers of that "duck type"?  Just search your code base for one of the method names?  Try to find every line of code that injects in a different duck type?

Not being able to surface an explicit interface leaves you stuck in a situation where you have to infer the relationship between your objects by finding every usage of them.  Seems like a lot more work, as well as being a recipe for tangled and confusing code.

So what do you think Dynamic language people?  Am I making a bigger deal out of the problems of dynamic typing just as Sandi made a bigger deal out of the problems of static typing?  Is this just a lack of experience problem?  Do you just not run into these issues that often in real world usage?

UPDATE 2/20/2013:
Here's an interesting presentation by Michael Feathers about the power of thinking about types during design.  I felt like it had some relevance to the conversation here.

In The Midst of Wonders

"Where the uninformed and unenquiring eye perceives neither novelty nor beauty, he walks in the midst of wonders" - John Hershel, from The Age of Wonder, originally from A Preliminary Discourse on the Stud of Natural Philosophy

Custom and Example

"I thus concluded that it is much more custom and example that persuade us than any certain knowledge, and yet inspite of this the voice of the majority does not afford a proof of any value in truths a little difficult to discover, because such truths are much more likely to have been discovered by one man than by a nation." - Rene Descartes, Discourse on Method and Meditations

The Basics

Some body I follow on twitter retweeted this tweet from Tim Ottinger:

The reason for writing a function is not to reuse its code, but to name the operation it performs.
— Tim Ottinger (@tottinge) January 22, 2013

My first pompous thought was something like, "how obvious."  I was about to go back to work when a memory hit me out of no where.  I remember very early in my career F5-hacking on some code and thinking about creating a method but worrying about not reusing it, or about someone else reusing it incorrectly, or about the extra lines of code the added syntax would add to my already 1000+ line Windows Form class.

I remember programming like that.  There was a time, not long ago, when I didn't think I should extract a method unless I meant to use it more than once!  And it's weird because I don't remember having the epiphany that took me from where I was then to where I am now.  I once thought A, I now think B, and I don't remember changing my mind.  It's an interesting lesson in the way the mind works.  And it reminded me that everyone was a newbie once, and that most likely, I still am a newbie I just haven't figured it out yet.