Mfcttrf

Throughout the course of programming, you will end up with some comments that explain code and some comments that are removing code:

// A concise description 
const a = Boolean(obj);
//b = false;

Is there a good method to quickly parse which is which?

I've played around with using 3 /'s and /** */ for descriptive comments.

There is a very simple solution to this: remove the commented-out code.

Really, there are only two good reasons to comment out code: to test something/make a fix, or to save code you might use later. If you're testing or fixing something, remove the commented out code as soon as you're done with the test or fix. If you're saving code you might use later, make it first-class code and put it somewhere such as a library where it can be put to good use.

Hmm, I read this question slightly differently from Robert who correctly asserts that commented out code should be removed.

If, however, you are looking for a convention to mark code for later removal, an old favorite of mine is //b = false; //TODO: remove

Some IDE's flag //TODO: comments or can be taught to. If not, it's usually a searchable string. It's best to follow whatever convention your shop has established because this can be done several ways. Every code base should do this one way. Keeps it searchable.

quickly parse which is which?

Without that mark the automated way to do this is with the compiler. If stripping the comment off produces code that compiles, it must have been commented code. Writing an IDE plugin that checks that wouldn't be hard. But it will leave buggy commented code behind.

This is why it's better to simply mark commented out code as code the moment you comment it out. This lets you work non-destructively while you decide if you really want it gone. Since we all get interrupted, and are somewhat forgetful, don't be surprised if some lines get checked in while in that state. If they do it's nice that they're at least clearly marked and searchable. Keyboard macros have helped me with this in the past. It's hard to get interrupted in the middle of this if you can do it with a single keystroke.

You can take this as far as enshrining the mark in your continuous integration tests. Oops, I'm trying to check in with outstanding TODO's again.

Adding to @RobertHarvey's excellent answer I believe there is only one legitimate reason I've ever encountered for saving commented code to source control, even temporarily: in case of a non-obvious improvement which depends on some third party change. This could be a bug or a feature of the language which is not yet considered stable. It might look something like this:

# TODO: Replace with `foo = frobnicate(bar)` once <link.to/bug> is fixed
foo = [some complex workaround]

Basically, the work has already been done, but you can't yet take advantage of it, so deleting it means someone would have to rediscover it later.

I agree with the answer stating that old code should be removed rather than commented out where possible, however I have observed a convention for those few occasions when commented-out code is needed.

(My basis is C# but this can be applied to any C-syntax language eg java)

// An explanatory comment has a space between the comment marker and the content.

// The following lines are commented out code so do not have the space (except where indented).
//var a = something();
//if(a==2) 
// doSomethingElse();
//

If you use an editor with a compiler running in the background (like Xcode and Clang), you can just try to compile the text of the comment. For example”a concise description” gives errors, “b = false;” doesn’t. You could then use different syntax highlighting.

A simpler method would be an IDE plugin that uses some heuristics, like multiple words in a row other than keywords points to comments, matched curly braced point to code etc.

I am interpreting the question different still, thinking you want to find commented out code.

C-style code is bound to have semi-colons in it while comment is unlikely to have semi-colons in it. So for single line commented-out code you could use this regular expression:

s*//[sS]*;

For multi-line commented-out code it could be

/*[^;]*;[^;]**/

Note Visual Studio is a bit peculiar about line breaks in regular expressions, they do not count as whitespace, you need to specify an explicit n.