Is it BAD to leave commented out code in your code base when you check files into source control? Is this a STIG? I know Unused code is a STIG, but how about commented out code - say to leave for a future developer IF they need that functionality eventually?
If using a source control system you could perhaps just leave a comment telling about what and when it was removed rather than really leaving the code ? If the code is needed it could be then retrieved from the scs ?
If using a source control system you could perhaps just leave a comment telling about what and when it was removed rather than really leaving the code ? If the code is needed it could be then retrieved from the scs ?
Yes, that is a valid answer... so I guess just point to what file possibly has the code in the source control history?
Also, do you know if there is a STIG for this? I can't seem to find one.
What do you mean with a STIG? The first thing a search left me was the mysterious driver of Top Gear (https://en.wikipedia.org/wiki/The_Stig) but my guess is you mean something else.
For projects I'm working on I leave commented out code. Perhaps I need to uncomment them some reason in the future or while in development it can be handy to see what was the history of some method.
However I also have a backlog item near the end of the sprint or after delivery of the product to clean out these commented out things (after taking a delivery-branch of the code at that moment).
Kris.
Read my blog | Twitter Working with Azure, chatbots, ASP.NET MVC, Web API, EF, MS SQL, ...
Keep the forums clean: report to the moderation team!
What do you mean with a STIG? The first thing a search left me was the mysterious driver of Top Gear (https://en.wikipedia.org/wiki/The_Stig) but my guess is you mean something else.
For projects I'm working on I leave commented out code. Perhaps I need to uncomment them some reason in the future or while in development it can be handy to see what was the history of some method.
However I also have a backlog item near the end of the sprint or after delivery of the product to clean out these commented out things (after taking a delivery-branch of the code at that moment).
Not sure really how it is related to security. I would say that it highly depends on what this code does (as in practice what the code you are removing does will likely play a high role in keeping it as a comment or deleting it without even wondering).
I guess you have never been in a satiation where code is being maintenance by multiple developers, a developer was too lazy or scared to delete out code that was no longer viable, and they just commented it out. There is nothing worst than seeing commented
out code that should have been deleted out of the solution, which should have been deleted out.
That's why solutions like TFS and other code repositories when used with Visual Studio allow code comparison with a compassion tool so the developer can track code changes in the source code to identify code changes and with the ability to add comments on
code check-in. There is no reason to keep dead code commented out in the code base.
If you find the post has answered your issue, then please mark post as 'answered'.
Participant
1033 Points
2772 Posts
Commenting out code in your application
Jan 03, 2018 01:36 PM|tvb2727|LINK
Is it BAD to leave commented out code in your code base when you check files into source control? Is this a STIG? I know Unused code is a STIG, but how about commented out code - say to leave for a future developer IF they need that functionality eventually?
All-Star
47410 Points
17539 Posts
Re: Commenting out code in your application
Jan 03, 2018 01:45 PM|PatriceSc|LINK
Hi,
If using a source control system you could perhaps just leave a comment telling about what and when it was removed rather than really leaving the code ? If the code is needed it could be then retrieved from the scs ?
Participant
1033 Points
2772 Posts
Re: Commenting out code in your application
Jan 03, 2018 01:47 PM|tvb2727|LINK
Yes, that is a valid answer... so I guess just point to what file possibly has the code in the source control history?
Also, do you know if there is a STIG for this? I can't seem to find one.
All-Star
191663 Points
20944 Posts
ASPInsiders
Moderator
MVP
Re: Commenting out code in your application
Jan 03, 2018 01:47 PM|XIII|LINK
Hi,
What do you mean with a STIG? The first thing a search left me was the mysterious driver of Top Gear (https://en.wikipedia.org/wiki/The_Stig) but my guess is you mean something else.
For projects I'm working on I leave commented out code. Perhaps I need to uncomment them some reason in the future or while in development it can be handy to see what was the history of some method.
However I also have a backlog item near the end of the sprint or after delivery of the product to clean out these commented out things (after taking a delivery-branch of the code at that moment).
Kris.
Working with Azure, chatbots, ASP.NET MVC, Web API, EF, MS SQL, ...
Keep the forums clean: report to the moderation team!
Participant
1033 Points
2772 Posts
Re: Commenting out code in your application
Jan 03, 2018 02:14 PM|tvb2727|LINK
Here is what a STIG is: http://blog.vaulted.io/what-is-a-security-technical-implementation-guide-stig
I agree with your thought process. Since it is commented out code, it should not be compiled.
Just trying to find if leaving it in is a STIG violation or not. If it is: what level? Cat 1, Cat 2 etc?
All-Star
47410 Points
17539 Posts
Re: Commenting out code in your application
Jan 03, 2018 05:51 PM|PatriceSc|LINK
Not sure really how it is related to security. I would say that it highly depends on what this code does (as in practice what the code you are removing does will likely play a high role in keeping it as a comment or deleting it without even wondering).
Contributor
4623 Points
3906 Posts
Re: Commenting out code in your application
Jan 03, 2018 11:38 PM|DA924|LINK
I guess you have never been in a satiation where code is being maintenance by multiple developers, a developer was too lazy or scared to delete out code that was no longer viable, and they just commented it out. There is nothing worst than seeing commented out code that should have been deleted out of the solution, which should have been deleted out.
That's why solutions like TFS and other code repositories when used with Visual Studio allow code comparison with a compassion tool so the developer can track code changes in the source code to identify code changes and with the ability to add comments on code check-in. There is no reason to keep dead code commented out in the code base.