Whenever I find out that a large portion of my code needs to be changed, either because it is incorrect or because it needs to be adapted to major architectural changes necessited by other reasons, this is what I typically do:

  1. I comment out all code that I suspect I might have to change. I treat the commented out code as a sort of my TODO-list.
  2. I gradually review the commented out code and uncomment parts of this code, or copy-paste them elsewhere and then edit them as necessary, or rewrite parts of this code from scratch, looking at the commented out code for reference. Whenever I think I'm done with a part of the commented out code I remove it.
  3. I continue this until I can see no more commented out code.

I should note that I'm largely doing this on the personal project that I'm developing alone.

However, I was told, that I should stop doing this. I was told that instead, I should start using git, referring to old commits to see old code, instead of leaving commented out code. I was told:

Commenting out code is a bad habit that should be wiped out. You lack experience so you fail to understand that. If, in a few years, you see code of another person who likes commenting out code, you will yourself start swearing at this person. Whenever I see commented out code, I remove it in its entirety, without even looking at it, because usually such code is completely worthless. You will certainly fail to see the downsides of commenting out code in small, one-person projects; but if you find a job and keep this habit there it will be a shame.

May I ask what are these downsides of what I'm doing that I'm failing to see now?

I must say I'm not really keen on only using git to see past code. As I said, I treat commenting out code as a sort of a todo-list; while git will show me how the code used to be looking, it will fail to clearly show me which parts of code are still necessary to be reviewed and which are already done. I fear I may miss some part of code and introduce bugs.

For completeness, I feel I should add that the person I'm quoting is an experienced developer and a fan of Uncle Bob's "Clean Code" - and Uncle Bob did criticize commenting out code harshly in his book.

  • 1
    Are you committing the commented code to version control? Aug 20, 2018 at 21:33
  • 1
    @Goyo I was not using version control at all. I was told I definitely should start using version control (even though it is a one man personal project) and that, among others, version control will allow me to stop commenting out code (which I should).
    – gaazkam
    Aug 20, 2018 at 21:35
  • 4
    If the commented code is not visible in the master branch after you merge back (and you can do that) who will be hurt?. If you feel the need to commit before getting rid of the commented-out code that hints that you might be taking too big steps, but that is a different matter. Aug 20, 2018 at 22:20
  • 5
    It is true that if you cmoment code, you can easily undone it by uncomment it, however if you have change ssome stuff in quite some files and need to go back, you're quite screwed without version control. So "start using source control" should be way above your priority than "not commenting code" :)
    – Walfrat
    Aug 21, 2018 at 14:45
  • 3
    Wait, you wrote you have a code base which is large enough that portions of it sometimes "need to be adapted to major architectural changes" - and you are CURRENTLY NOT USING VERSION CONTROL? WTF - seriously? You are joking, aren't you? If that is really true, you have larger problems than the question if your way of working with outcommented code is ok or not.
    – Doc Brown
    Aug 21, 2018 at 18:14

6 Answers 6


If you ultimately remove all of the commented out code, I see no real issue with this. Leaving commented code in your code base is a bad practice but that is not what you are doing if you work through it all and eliminate it. I suspect the person you are talking to either doesn't understand the process you are using or is being dogmatic.

In reality, commented code is harmless. The problem is that it's messy and makes it difficult to read. There are far worse sins but it's a very simple thing to eliminate. As the person who commented out the code, you are in the best position to determine that it can be completely removed.

A lot of IDEs and code editors understand some sort of 'TODO' syntax in comments. This is an alternate way to mark what needs to be changed. You might want to consider this since it give a little more information about what you were thinking when you marked it.

At the end of the day do things the way that results in the best outcome for you. Even if this were a team project, as long as you remove all the commented code you aren't burdening anyone else.

  • I can't remember where I heard it, but there is an argument that in general commented out code is not harmless as it never gets refactored. Note that this presupposes you will eventually un-comment and re-use that block of code.
    – Peter M
    Aug 24, 2018 at 13:27
  • @PeterM The point here is that it's fine as long as you get rid of it. You should not be leaving commented code in your code base. Something I often do when refactoring is comment out variables to see how many errors that creates to help me understand how much work it will be. Depending on what I intend to do, I might leave it like that until I've resolved all those issues and then finalize the change by deleting the commented code.
    – JimmyJames
    Aug 24, 2018 at 14:48
  • 1
    I have several code bases I work on that are littered with TODO comments. It’s honestly not so bad because it’s usually 1-2 lines. The thing I like about TODO comments is that my IDE has a “TODO” tab near the terminal that auto-populates with that list of comments, with a preview of the comment and the file/line number. Point is, it’s useful when in a particular company they don’t gasp use Issues even though they use Git/Github. Yeah, well what can you do, try to convince management to use Git Issues instead of Google Sheets? Yeah, tried and failed. Oh well. TODO comments it is! Aug 27, 2018 at 0:05

May I ask what are these downsides of what I'm doing that I'm failing to see now?

Arguably, none if you work alone and don't use version control and feel it's ok to do it this way.

In fact, without version control it doesn't matter much what you do at any point in "time" as the code is always whatever state the current file is "saved" as in the operating system.

If you use version control, and you have a load of comments as your "todo list", and you fix some and remove the comment, then repeat, then repeat etc... you then have "work in progress" code and comments saved in your revision history. This won't be an issue if you never need to roll back to another commit or even "cherry pick" later (this eg is where you take specific commits and pull them into another branch to be used). But otherwise it might be a problem.

Arguably this can be compared to hard drive software "snap shots", like Windows had (the Restore thing). If it takes a snapshot with a virus in it, you kill the virus, but then later need to roll back, you can go back to a point where the virus is present again.

This approach is also likely to be a problem when you use version control and work with other devs, as then they have to see your todo list which has no use to them. In fact, it's just clutter they have to ignore and work around. In our teams we always remove all comments, such as old code or "notes". Unless they are useful - however this is very rare because we have documentation for "how it works", and software for tracking what needs to be done (aka todo).

Also, when working on a larger project you tend to collaborate, and commit and push often, so it's possible that their branch they're working on has your TODO list if they merged your branch in to theirs. Then your TODO list is everyone's business :D

In summary, if you don't work alone and especially when using version control, it clutters up the history and can be clutter to other devs.

And, this is a personal thing in some respects, but using a codebase as your "todo list" isn't ideal really. One day you might leave something in by accident, or forget to comment it or uncomment it by mistake.

As with a lot of approaches to architecture, coding, and how you personally or your team works, each scenario can call for something different. So consider the downsides mentioned, and the benefits of using version control, and decide whether it works for you.

  • This is why you work on feature branches and use squashed merges. Work in progress code should never be seen by another developer, hence it shouldn't matter what method was used to develop it.
    – Jules
    Aug 21, 2018 at 17:55

It sounds like your reviewer is a little dogmatic. I'm not sure swearing at someone for commenting out code is PC ;-), or even helpful ;-)

But more seriously, I think your reviewer IS right, that you should seriously consider using git (or some other source control system, but git is a sensible choice).

And that doing so may alleviate some of your needs to comment out code.

But having a TODO list within the code (whether bulleted lists or old code) - is quite reasonable in my opinion. But you may want to reconsider a bit about how you do it. For one thing - I suggest thinking about someone else reading your code. That someone else could be you, a year after you drop and rejoin a project. Or it could be someone else entirely. JUST encountering commented out code is a bit confusing. Maybe something like:

 * Need this sort of functionality added back before too long:

Personally, I lean more towards something like this:

 * TODO:
 *      @todo   Possible get rid of intermediate LRUCache_ object.
 *      @todo   Find some reasonable/simple way to get
 *              LRUCache<PHRShortcutSpec, PHRShortcutSpec, PHRShortcutSpecNoAuthCacheTraits_>   sRecentlyUsedCache (kMaxEltsInReceltlyUsedCache_);
 *              Working with ONE T argument
 *              Add(elt2cache).

and I feel free to throw in 'code snippets' from old code as helpful.

Using git is hard (sadly). It will take you a while to learn, and it may feel like its not part of what you are trying to accomplish. But if you are going to program usefully, you will need to learn to do so as part of a team, and communicating with a team, and git is just how that is done nowadays. And once you've gotten to using it, you will find its a VERY helpful tool/crutch, making your software development easier.

Best of luck!


There are many reasons to comment out code:-

  • It's not right yet, and you'll un-comment it when it's ready.
  • You are temporarily commenting it out to change the behaviour while debugging.
  • You're not sure if the code is needed, but don't want to delete it until you've tested some more.
  • The code is needed for some versions of the software, but not this one.
  • The code is obsolete, but it took ages to write and you're emotionally attached to it. Besides, it might be useful one day.

The problem comes when you put the code to bed, then come back to it a couple of years later to do some maintenance. You will find the codebase littered with commented out code. It will no longer be clear why any of it is there, and it's now just clutter.

If you use any half-decent version control tool, you can boldly delete any code that you don't need any more, safe in the knowledge that the version control system still has it stored away. A file diff between versions will reveal what was deleted. Once you've implemented version control, the only need for commenting out is for temporary stuff. If you ever find commented out code in files you aren't actually working on, you can just delete it.

  • 1
    These are exactly the reasons why you should rather use a SCM (and cranches within it) Aug 21, 2018 at 11:06

It's bad and you should stop.

The reason boils down to attempting to do a large amount of refactoring in one go.

If you comment out large sections of code, fix a little bit and check in, then you have checked in non-functional code. and a whole load of commented out stuff that others will assume is old and can be ignored

If you don't check in often, then you are accumulating merge conflicts and not recording step by step progress.

You need to change your working practice so that if you have to stop mid way everything still works.

Take baby steps and check in after each:

  • extract an interface
  • write a test
  • refactor a function

Don't mark off large chunks of code as 'yours' by commenting them out and take them away to work on by yourself until they are complete or you fail.

If you need to keep track of what needs to be done, use a task board like scrum or trello


I'm not going to reiterate why you should use source control even for one-person projects, as there are plenty of other resources out there which will tell you to do this. But one major related downside of your current approach is that if you comment out code, you hide it from your IDE (if you're not using an IDE you should probably consider it).

For example, if you want to rename a method or class, or change the number of parameters a method takes, your IDE should have a refactor option to do this which will find all the appropriate references and update them accordingly - but it probably won't search in comments.

Instead of trying to guess where you need to make changes, just make them them and let your IDE tell you where your changes have caused things to break. You can then comment out the code more surgically, and hopefully for a shorter period of time before you fix whatever broke.

Not the answer you're looking for? Browse other questions tagged or ask your own question.