Mdthbs

What purpose does mercury dichloride have in fireworks?

How to gather entities into sets?

Can one block with a protection from color creature?

What is the shape of the upper boundary of water hitting a screen?

What is this burst transmission sequence across the entire band?

Wouldn't putting an electronic key inside a small Faraday cage render it completely useless?

Computer name naming convention for security

Why do Martians have to wear space helmets?

How can I review my manager, who is fine?

Category-theoretic treatment of diffs, patches and merging?

Which is a better conductor, a very thick rubber wire or a very thin copper wire?

Four ships at the ocean with the same distance

How did the IEC decide to create kibibytes?

Those who speak do not know, those who know do not speak

Possibility to correct pitch from digital versions of records with the hole not centered

What do you call a situation where you have choices but no good choice?

When is one 'Ready' to make Original Contributions to Mathematics?

QR codes, do people use them?

What does "spinning upon the shoals" mean?

Is it ok for parents to kiss and romance with each other while their 2- to 8-year-old child watches?

How to say "is going" in Russian in "this game is going to perish"

Array or vector? Two dimensional array or matrix?

If a caster wants to use a spell scroll as a reaction, do they need to already be holding it in their hand?

Can a USB hub be used to access a drive from two devices?

Does anyone have a method of differentiating informative comments from commented out code?

Is commented out code really always bad?Where should I include comments in my “self-documenting code”?How to discriminate commented code and documentation commentsCode maintenance: To add comments in code or to just leave it to the version control?Can commented-out code be valuable documentation?Why are we supposed to use short functions to sectionalize our code?How to write comments to explain the “why” behind the callback function when the function and parameter names are insufficient for that?What's wrong with comments that explain complex code?Clean Code comments vs class documentationIs a JS Boolean having custom properties a bad practice?

.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ margin-bottom:0;
}

4

1

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;

Are there any good methods to quickly parse which is which?
I've played around with using 3 /'s and /** */ for descriptive comments.

javascript comments

share|improve this question

edited 7 hours ago

Ace

asked 8 hours ago

AceAce

12644 bronze badges

New contributor

Ace is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.

• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  This question might benefit from specifying the language/framework/IDE-tooling, as those can impact how comments are written/viewed/searched.
  
  – Graham
  8 hours ago
  

  
  
  
  

add a comment | 

4

1

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;

Are there any good methods to quickly parse which is which?
I've played around with using 3 /'s and /** */ for descriptive comments.

javascript comments

share|improve this question

edited 7 hours ago

Ace

asked 8 hours ago

AceAce

12644 bronze badges

New contributor

Ace is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.

• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  This question might benefit from specifying the language/framework/IDE-tooling, as those can impact how comments are written/viewed/searched.
  
  – Graham
  8 hours ago
  

  
  
  
  

add a comment | 

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;

Are there any good methods to quickly parse which is which?
I've played around with using 3 /'s and /** */ for descriptive comments.

javascript comments

share|improve this question

edited 7 hours ago

Ace

asked 8 hours ago

AceAce

12644 bronze badges

New contributor

Ace is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.

// a concise description 

const a = Boolean(obj);

//b = false;

share|improve this question

edited 7 hours ago

Ace

asked 8 hours ago

AceAce

12644 bronze badges

New contributor

Ace is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.

share|improve this question

edited 7 hours ago

Ace

asked 8 hours ago

AceAce

12644 bronze badges

New contributor

Ace is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.

asked 8 hours ago

AceAce

12644 bronze badges

New contributor

Ace is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.

asked 8 hours ago

AceAce

12644 bronze badges

3 Answers
3

active

oldest

votes

14

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.

share|improve this answer

edited 8 hours ago

answered 8 hours ago

Robert Harvey♦Robert Harvey

170k4646 gold badges400400 silver badges609609 bronze badges

• 
  
  
  

  
  7
  

  
  
  
  
  
  

  
  
  Also, if the code has been checked in: just remove it. If you ever need it back, source control has got you covered
  
  – marstato
  7 hours ago
  

  
  
  
  

add a comment | 

3

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.

share|improve this answer

edited 6 hours ago

answered 6 hours ago

candied_orangecandied_orange

58.6k1818 gold badges117117 silver badges202202 bronze badges

add a comment | 

0

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.

share|improve this answer

answered 5 hours ago

Martin MaatMartin Maat

8,79022 gold badges1111 silver badges3535 bronze badges

add a comment | 

Your Answer

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "131"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});

Ace is a new contributor. Be nice, and check out our Code of Conduct.

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Post as a guest

Name

Email

Required, but never shown

StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsoftwareengineering.stackexchange.com%2fquestions%2f394287%2fdoes-anyone-have-a-method-of-differentiating-informative-comments-from-commented%23new-answer', 'question_page');
}
);

Post as a guest

Name

Email

Required, but never shown

14

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.

share|improve this answer

edited 8 hours ago

answered 8 hours ago

Robert Harvey♦Robert Harvey

170k4646 gold badges400400 silver badges609609 bronze badges

• 
  
  
  

  
  7
  

  
  
  
  
  
  

  
  
  Also, if the code has been checked in: just remove it. If you ever need it back, source control has got you covered
  
  – marstato
  7 hours ago
  

  
  
  
  

add a comment | 

14

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.

share|improve this answer

edited 8 hours ago

answered 8 hours ago

Robert Harvey♦Robert Harvey

170k4646 gold badges400400 silver badges609609 bronze badges

• 
  
  
  

  
  7
  

  
  
  
  
  
  

  
  
  Also, if the code has been checked in: just remove it. If you ever need it back, source control has got you covered
  
  – marstato
  7 hours ago
  

  
  
  
  

add a comment | 

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.

share|improve this answer

edited 8 hours ago

answered 8 hours ago

Robert Harvey♦Robert Harvey

170k4646 gold badges400400 silver badges609609 bronze badges

share|improve this answer

edited 8 hours ago

answered 8 hours ago

Robert Harvey♦Robert Harvey

170k4646 gold badges400400 silver badges609609 bronze badges

answered 8 hours ago

Robert Harvey♦Robert Harvey

170k4646 gold badges400400 silver badges609609 bronze badges

answered 8 hours ago

Robert Harvey♦Robert Harvey

170k4646 gold badges400400 silver badges609609 bronze badges

3

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.

share|improve this answer

edited 6 hours ago

answered 6 hours ago

candied_orangecandied_orange

58.6k1818 gold badges117117 silver badges202202 bronze badges

add a comment | 

3

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.

share|improve this answer

edited 6 hours ago

answered 6 hours ago

candied_orangecandied_orange

58.6k1818 gold badges117117 silver badges202202 bronze badges

add a comment | 

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.

share|improve this answer

edited 6 hours ago

answered 6 hours ago

candied_orangecandied_orange

58.6k1818 gold badges117117 silver badges202202 bronze badges

share|improve this answer

edited 6 hours ago

answered 6 hours ago

candied_orangecandied_orange

58.6k1818 gold badges117117 silver badges202202 bronze badges

answered 6 hours ago

candied_orangecandied_orange

58.6k1818 gold badges117117 silver badges202202 bronze badges

answered 6 hours ago

candied_orangecandied_orange

58.6k1818 gold badges117117 silver badges202202 bronze badges

0

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.

share|improve this answer

answered 5 hours ago

Martin MaatMartin Maat

8,79022 gold badges1111 silver badges3535 bronze badges

add a comment | 

0

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.

share|improve this answer

answered 5 hours ago

Martin MaatMartin Maat

8,79022 gold badges1111 silver badges3535 bronze badges

add a comment | 

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.

share|improve this answer

answered 5 hours ago

Martin MaatMartin Maat

8,79022 gold badges1111 silver badges3535 bronze badges

s*//[sS]*;

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

share|improve this answer

answered 5 hours ago

Martin MaatMartin Maat

8,79022 gold badges1111 silver badges3535 bronze badges

answered 5 hours ago

Martin MaatMartin Maat

8,79022 gold badges1111 silver badges3535 bronze badges

answered 5 hours ago

Martin MaatMartin Maat

8,79022 gold badges1111 silver badges3535 bronze badges