- Feature Articles
- CodeSOD
- Error'd
- Forums
-
Other Articles
- Random Article
- Other Series
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Edit Admin
No, no, no, no, no, no. Purge the evil from among your codebase.
If you leave it there, then one day someone will have a problem, find this code, and the frist thing they'll say is "That can't be right. Some fool named GRH commented out the code and then forgot to reinstate it."
Edit Admin
For shame, GRH!
To be clear, without the commented out lines, the last part of the function is this:
Admin
Smart move to keep these plain text passwords in the code base, GRH! What can be more secure?
Edit Admin
Yeap. But I have seen people say it's easier (WTF???) to see commented out code in the file than to just go back in version control. Same with people who insist on having changelogs in the code because you don't have to look into version control to see who changed what.
Edit Admin
In my experience, those people are also ones who learned programming before version control was a thing. You never delete; Only comment it out. Because learning how to search the history is harder than just reading the comments.
Edit Admin
The problem is that when code is deleted, you don't know there used to be something there, so you wouldn't even know to run blame on that block of code to see who removed it.
A compromise could be to replace it all with a comment saying "Removed a bunch of useless code here".
Edit Admin
Sometimes I do see the benefit of the change log (in stored procedures for example it's MUCH easier to see a comment up top what was changed than dig through version control) but a lot of times it's just an excuse to keep old code "in case we need it"
Edit Admin
To which the answer is "well, if we need it, we'll dig it out of the old versions in version control."
Edit Admin
I used to think this might be the case, but I see as many young programmers do this as experienced ones.
I know a guy that actively resists this change even when I show him that although it's faster to see a change by looking at the code and seeing the old version, it's far easier to see what has changed by using the diff tool in source control. Often, the line has a subtle change, and commenting out the old one and adding a new one diffs like an addition of code, giving no comparison at all. Changing the line allows the diff tool to point out the exact difference.
So, since this affects the rest of the team supporting his code changes, he is not permitted to override team decisions "because it's easier for him".
Edit Admin
Does your source control tool not have an equivalent of SubVersion's "blame" feature where is displays an annotated version of the file in a special viewer that makes it much easier to see who changed what and when than actually reading through a list of comments that are "probably correct"?
Edit Admin
Actually it's either ".net framework" or ".net core" - actually now it's just ".net". IK, the naming is nearly as bad with Java's editions, even though MS had the golden opportunity to stick with "netcore" but they really wanted to hammer down that mono got fully integrated with ".net 5" - which itself is funny, because there was no ".net 4" so that there is no confusion with ".net framework 4.x" - after a lot of developers got confused by ".net standard".