.NET Tips and Tricks

Blog archive

Comment Out Code, Quick

I never delete code -- you never know when you might want it back. So I spend a lot of time commenting out code. I do this so often, and mousing up to the menu takes so long, that I've memorized the keystroke combination for commenting/uncommenting code. It’s actually one of the few keystroke combinations -- other than Undo -- that I remember.

To comment a group of lines, first select the lines. Then, holding down the Control key throughout, press K, then C. To uncomment, hold down the Control key and press K, then U. (These two stroke combinations are called "chords.")

Do you have a Visual Studio tip, you'd like to share? Send it to me at phvogel@1105media.com.

Posted by Peter Vogel on 04/19/2011 at 1:16 PM

comments powered by Disqus

Reader Comments:

Fri, Sep 28, 2012

Just amazing how many people are willing to waste their time arguing over something obvious

Tue, May 15, 2012 Edmundo

Oh, god... that was painful to read. So you might want your code back? How about using source control? Having DVCSs (git, bzr, hg to name just 3 of them) available nowadays it's just a matter of seconds to be able to start using it on a project so it makes no sense no _not_ use it.

Wed, Mar 28, 2012 Rob Blackwood New Hampshire

I'm with you Peter Vogel, even though I will delete code; commented-out code provides a direct way to communicate to the editor the way something used-to-be or an alternative. Whenever I leave "dead code" it's to leave some useful bit of information, or I'm unsure that I will not go back to using it.

Thu, Dec 29, 2011 join

http://w DOT ww.shortuggoutlet.com http://w DOT ww.uggstore-order.com http://w DOT ww.v-shoes.com http://w DOT ww.uggshop-outlet.com http://w DOT ww.germe.org

Wed, Oct 26, 2011

You're doing it wrong.

Wed, May 4, 2011 Neil

What a terrible idea. This post should be banned from they eyeballs of any jr. dev not yet able to find the forehead slapping humor in it.

Tue, Apr 26, 2011 King Whitey New Jersey

Code Hoarder!

Mon, Apr 25, 2011 Phil NY

Oh, my dear.

Listen, if you're not using code, STRIP IT OUT. Otherwise, all you've accomplished is collecting cruft that someone else is going to have to sort out one day.

If you think you might want to re-use a bit of code, strip it out and store it in a separate text file in your home directory, for your personal use. Don't burden the rest of your organization with it.

Crufty code is not good code.

Mon, Apr 25, 2011 Peter Moberg

You are joking, right? Ever heard of source control?

Sun, Apr 24, 2011 Jace Atlanta

In all seriousness, I thought this was a joke too. I get the sense from some of your follow-up comments that maybe your codebases are your own. In which case, do whatever. The problem with commenting-out code is that it wastes cycles for other developers visiting this module for the first time. I'm Joe Teammate, and I have to go work on a module you wrote because you've been on vacation. I take a look at the code and see two versions. One is commented out, and I have a bug to fix. Is the commented-out version correct? Was it supposed to come back in? Is the version that's running some sort of stub? Is that why I have this bug? Now I have to read and understand and compare and contrast both versions. And once I do that, I can begin on my task. Do you see why people can have such violent reactions to vistigial limbs and evolutionary dead ends in comments? The code should reflect our best understanding of the problem domain, right now. If our understanding gets better, we change the code to reflect it, and throw out our old misunderstandings. The next person who comes along will see our best understanding, uncluttered, and we can still get to old code by doing diffs. The price we pay working with source control saves our teammates threefold.

Sat, Apr 23, 2011 Horia Dragomir (http://horia.me) Romania

This is a joke, right?

Sat, Apr 23, 2011 Peter Vogel Canada

Misterm: I can see your point about the wording in my tip--it just didn't occur to me that it could be read that way. Of course, I frequently rewrite code to make it better (or just to make it work)--I'm a big fan of refactoring. But I have to admit, it's unusual for me to remove code. While my first idea isn't always my best idea, it's not without some value. For instance, I had a routine that was to handle data coming in through a serial port. It was important to eliminate duplicate entries, provided those entries came within a specific time frame. The original version of the method was quite lengthy and I realized that the way I was solving the problem wasn't optimal. I replaced the method with a "more elegant" solution. But that old code still had some neat features and I could see where I might want it again. I haven't yet found a good place to keep code so I can find my way back to it when I need it. I've found, over the years, that what I remember about code is where I used it so that provides the best way of finding my back to it. It's funny you mention the meta-data because I do add comments about why I replaced the code (good code is self-explanatory about the "how" it works but it's often difficult for code, by itself, to explain the "why" it's there).

Sat, Apr 23, 2011 misterm

Having (small) bits of code (occasionally) in the comments by means of explanation I can get on board with....especially if it's just the algorithm or pseudo-code. Still, I would say there are *very* few instances where you should be straight up commenting blocks of code for the purposes of preserving it for whatever reason. (Code blocks should only be commented out briefly, for testing etc). The first words of this post are "I never remove code" (or something to that effect). Even allowing literary license that's a rather strong endorsement of what is at best a "good enough" temporary documentation hack. If you feel it's important to note, add a comment like: /* Used to use someLibrary.fooFighter() here, but [it's slow, not thread-safe, etc], so now a [more efficient, better, etc] otherLibrary.barKiller() version is used. See commit #XYZ in the Dev branch. */ If you're going to leave chunks of code in your code-base, you certainly should at least explain WHY it's there, and if you're using a good VCS then once the explanation is n place, the commented out code becomes extraneous.

Sat, Apr 23, 2011 Peter Vogel Canada

Well, actually that is my point: The diff command gives me the evolution of my code rather than a copy of "the method" or the "the algorithm." The commenting method lets me freeze one version of the code that, for whatever reason, I feel is valuable and will want at some point (milestones do the same thing for me but at a much larger level). I use source control/diff to track the changes/evolution of the code (version control's intended purpose). But, at the same time, I'm using source control for a purpose it wasn't intended: as a repository for code I think has value though it isn't useful in its current location. Since this came up, I've been thinking about it and, it seems, that I've decided that the various source control systems I've used had most of the functionality that I wanted for the code repository I haven't been able to find(though that wasn't their intended purpose). That does make a certain kind of sense: these systems are source code tracking tools, after all.

Sat, Apr 23, 2011 misterm

I'm trying to be open-minded...really. However, I can think of a million reasons why this is a **bad** idea, and not single one why it is a good one. Pete, can you provide some examples as to what this accomplishes that source control doesn't (besides cluttering up your code)? Version Control Systems will not only allow you to accomplish **anything** you could do with this, they be much more sophisticated and powerful without the drawbacks. Can you explain how this is better than just going through your VCS log/ Diff? The only possible benefit I can think of is it saves you of having to actually use the diff command, as your codebase is essentially in "diff" mode perpetually...but compared to the diff tool in a VCS, it is crappy and unsophisticated with none of the great tools VCS would provide... As already mentioned it also bloats your code base and makes it harder to read. Where exactly is the win here?

Fri, Apr 22, 2011 Justin Chase United States

hahaha! Oh wait, I thought this was the onion for a second.

Fri, Apr 22, 2011 Peter Vogel Canada

Actually, what's been most interesting about this column has been the responses. The first thing that surprised me was the number of people who assumed from five words ("you might want it back"--in retrospect, I'd leave out the word "back") that I don't use source control (is that even an option anymore?). One responder went from there to suggesting that I don't use TDD. I guess I can see the assumption that I might not use source control but the leap to TDD was especially interesting because 30 seconds with Google would have turned up some of the articles I've written about TDD. While many commenters were concerned about the source control issue and wanted to offer advice to other readers (and, I guess, to me) others felt they added value just by expressing their heartfelt opinion about the article's author ("you should be shot" being the most extreme example of those). I'm sort of surprised that no one has suggested a good code repository (several readers recommended keeping old code in parallel txt files which doesn't sound like a bad idea but doesn't sound optimal, either). You wonder if there's an opportunity out there for someone to deliver a useful code repository. I've tried a couple (even used EverNote for awhile because clipping was so easy) but I haven't found anything I liked...yet.

Fri, Apr 22, 2011 Peter Vogel Canada

I am amazed at the number of people who regard old code as junk or something that you have to "wade through." I regard old code as a resource. I've tried creating code libraries in the past but I've found that I best remember where code is based on the application I created it for (or where I last used it). And I'm a big fan of TDD--it's essential to both productivity and reliability. With TDD, it takes me a long time before I'm willing to remove a test: tests are a more useful resource than code. So I don't delete old tests I don't comment them out: I mark them with the Ignore attribute to remind me that I thought this test mattered--was I wrong to include it at first or wrong to exclude it later?

Fri, Apr 22, 2011 technikhil

Commented code is a code small IMO - http://technikhil.wordpress.com/2010/02/18/commented-code-is-a-bad-code-smell/ At least pity the poor sap who has to come in after you leave a project and wade through all your commented code. (resubmitting this since the initial one was swallowed)

Fri, Apr 22, 2011 technikhil

You should check out my rant about http://technikhil.wordpress.com/2010/02/18/commented-code-is-a-bad-code-smell/ DOT . This is bad code smell and you should avoid it. Pity the poor sap who come after you leave and has to wade through pages of full of commented code trying to understand what actually works.

Thu, Apr 21, 2011 The Baron ATL

I've got a shorter chord for you. Alt-F4. Next time you want to comment out code, try it instead.

Thu, Apr 21, 2011 Steve

Now text searches across a large source directory finds class references in all of your commented out code which influences refactoring and estimates. Sooooooo bad. If it is commented out, it has no value, not today, not tomorrow, never. It is just debt. Do you comment out that codes unit tests too? Let me guess, there aren't any.

Thu, Apr 21, 2011 Titan2782

If you're against source control and want to keep dead code around in case you need it, try cutting the code and you can then cycle your clipboard ring to get it back.

Thu, Apr 21, 2011

Thanks for this. I'm a pythoner using vim but this post has brought me laughter to the point of tears. Especially the date, 04/19/2011 .. hold on I need to laugh it off before I can type then rest of this comment. Anyways, thanks again.

Thu, Apr 21, 2011 Sara London

Epic fail. Please use Source control

Thu, Apr 21, 2011 James Austin, TX

I prefer to wrap old code in #if /#endif preprocessor directives. Then I can specify which version I want to compile and it uses that code. No need to remember those pesky comment/uncomment keyboard shortcuts #if V1 this is old code #endif jk :)

Thu, Apr 21, 2011 Chris A

You should be shot.

Thu, Apr 21, 2011 Chris J Great Britain

http://www.ascii-art.de/ascii/ab/badger.txt Grrrr!

Thu, Apr 21, 2011 Chris J Great Britain

Here's a good tip: Instead of filling your source with dead code, why not fill it with ASCII Art, you know pictures of things like maybe a badger or a racing car or a really awesome spaceship. Other developers that have to maintain your code will really appriciate it.

Thu, Apr 21, 2011 JJ

Yeah, you never know when you mich need a conditional clause, and this shortcut is way quicker than typing "if"...

Thu, Apr 21, 2011 Matt United States

Someone linked me to this just for the laugh. Nice work on figuring that out... On a serious note though, I remap my keys for commenting/uncommenting. I also don't like to keep a bunch of uncommented code as I like to keep my code as clean as I can. If I feel I have some code that I want to save for later for another project, I usually just store the snippet in SVN. Nothing new that hasn't been discussed before in this thread.

Thu, Apr 21, 2011 Eldon

I sometimes use source control systems. I never know when I might want my code back.

Thu, Apr 21, 2011

I've found a brilliant shortcut that will improve the quality of YOUR code, try Alt F4 after commenting out.

Thu, Apr 21, 2011 IB

I really wonder how much people are paying you to fill their code bases with crap. An awesome thought; I want to be like you.

Thu, Apr 21, 2011

Thanks for that. Really useful. Do you know whether there are any other things you can do using shortcuts?

Thu, Apr 21, 2011 Dermot Plymouth

May I commend you on your amazing ability to memorize keyboard shortcuts.

Thu, Apr 21, 2011 Ben


Thu, Apr 21, 2011 Ben

Extremely disappointing.

Thu, Apr 21, 2011 Peter Vogel Canada

Selim: I like the formatting commands--I was just selecting text and use the Tab key when indenting didn't come out the way I wanted. This is much more useful (provided I can remember the key combination--I'm more of a menu-and-mouse kind of guy).

Thu, Apr 21, 2011 Peter Vogel Canada

Dimitar: Ouch! That "come out of the 90s" comment stung :>. But just because code doesn't work in one place doesn't mean it won't be useful somewhere else. I don't regard that code as "junk" (to quote an earlier comment)--I regard old code as a resource. Hmmmmmm....maybe this a topic for a new reality TV show: "Software Hoarders."

Thu, Apr 21, 2011 Dimitar

I'm just like Peter Short, except that I use several stages usually called hello.backup.cs.txt, hello.backup2.cs.txt, hello.backup.final.cs.txt and hello.backup.finalfinal.cs.txt It's much easier to work this way! Geez, Peter (both of you) it's time to come out of the early 90s. Code that doesn't work should not exist, commented or not.

Wed, Apr 20, 2011 Peter Vogel Canada

Remapping the keyboard is a great way to personalize your Visual Studio UI to support you--it's something I think every developer should do to create an editor that works for you. Unfortunately, I don't get to do this. As a consultant, I spend a fair amount of time working on other people's computers: I stick with the vanilla keyboard. Nothing is more embarrassing then, right in front of a client, hitting some key combo...and have nothing happen (or, worse, something you don't want happens).

Wed, Apr 20, 2011 Peter Vogel Canada

Wow (or Geeeez...). The jump from wanting to keep old code to not using source control is a big leap...and not one that I'd be willing to make. I remember writing a front end for CVS in REXX on an IBM 4381 in the early 90s--and that wasn't my first version control system. But I do like keeping code around--just because it doesn't work here doesn't mean that it won't be useful somewhere else (and often a big help in understanding the existing code: maintaining code is as much about being a detective and historian as anything else). Unlike Peter Short, I'm too lazy to keep a separate code library: I use my client's repository as my library. The only objection I have to source control is that I keep having to change them (currently Subversion with Tortoise). Like I said: Geeez.

Wed, Apr 20, 2011 fwfulton Palm Bay FL

When I first read this I was these are WordStar commands (late 70's early 80's) but it just so happens they do work. I would never use this in place of source control they could be helpful sometimes in debugging.

Wed, Apr 20, 2011 Frank Rizzo United States

I agree it's stupid to do this when there is free source control products all over the place. But if you did want to comment/uncomment quickly, this is not the fast way. Alt+C/Alt+X is the way to go: http://www.angryhacker.com/blog/archive/2009/02/10/5-ways-to-be-a-more-efficient-developer-in-5.aspx

Wed, Apr 20, 2011 Peter Short Iceland

Trolls gonna troll :P I personally keep a txt file along side my cs file and give it a corresponding name, eg hello.cs gets a hello.safety.cs.txt and then if i want to take something out then i copy the code into that so i dont have ugly comments everywhere ruining my readability. If i want syntax highliting on these files i can simply change the notepad++ registration to recognize txt files as cs. EASY AND COOL.

Wed, Apr 20, 2011 Gary L Cox Jr Austin, Tx

LOL, I read this thinking it had to be posted on April 1rst. This has got to be a joke and meant for a good laugh.

Wed, Apr 20, 2011 Harry Steinhilber Southern NY

"You never known when you might want it back." OK, great. You comment out your code. later you rename a couple of variables, maybe a parameter. "Oh, wait, I do need this code." Uncomment the code - BOOM. You no longer compile. Great plan. Use source control for what it is meant for: versioning your code.

Wed, Apr 20, 2011

This is fucking bullshit. Leave it to a .NET developer to not fully utilize technology.

Wed, Apr 20, 2011 Brant

Is this a real tip or an Onion-esque satire?

Wed, Apr 20, 2011 JeroenH

How clueless can you be

Wed, Apr 20, 2011

No no no no no no no. "I never delete code -- you never know when you might want it back." -That's what source control is for. Also, you should never comment out code and then check it in. You have history in your source control for that. "Inline-history", as you call it, is a great way to confuse future maintainers and clutter your files with junk.

Wed, Apr 20, 2011 Code monkey

Wow this is BAD! I would NEVER hire you after reading this. dead code should never go into the repo. Version control is the solution. how would you remember what parts you need to uncomment ? Very often its not just a single chunk of code but spread out all over your source. And over time this would only get more and more messy. Say it with me: SOURCE CONTROL, SOURCE CONTROL, SOURCE CONTROL

Wed, Apr 20, 2011 John Byrne Melbourne, Australia

I always change my text editor to use 1 key to comment and uncomment - usually F8. This is much easier to use pressing 1 key rather than 3, and much easier to remember.

Tue, Apr 19, 2011 Peter Vogel Canada

Source control is good--but commented out code also provides a in-line history of changes to your code (and without running a diff operation).

Tue, Apr 19, 2011 Selim Redlands, CA

I agree with John. Unless you comment something out just to test something, commented code should never make it into the source control repository!this being said, a nice one is Ctrl-K + F or Ctrl-K + D that formats the current selection or document respectively. Very handy when the editor gets indentation all messed up. Ctrl+Shift+B is also very handy: it does a full build.

Tue, Apr 19, 2011 John Central NY

If "you never know when you might want it back" then it's a job for source control. Commenting out code is only for stuff that's coming back in the immediate future (e.g. not-finished-yet case or if blocks, "real" code being replaced with debugging code, etc.)

Add Your Comments Now:

Your Name:(optional)
Your Email:(optional)
Your Location:(optional)
Please type the letters/numbers you see above

.NET Insight

Sign up for our newsletter.

I agree to this site's Privacy Policy.