• (nodebb)

    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."

  • (nodebb)

    For shame, GRH!

    To be clear, without the commented out lines, the last part of the function is this:

            Try
            Catch ex As Exception
    
            End Try
    
  • Zatapatique (unregistered)

    Smart move to keep these plain text passwords in the code base, GRH! What can be more secure?

  • (nodebb) in reply to Paddles

    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.

  • (nodebb) in reply to DocMonster

    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.

  • (nodebb) in reply to colejohnson66

    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".

  • DQ (unregistered) in reply to colejohnson66
    Comment held for moderation.
  • (nodebb) in reply to Barry Margolin

    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"

  • (nodebb) in reply to DocMonster

    To which the answer is "well, if we need it, we'll dig it out of the old versions in version control."

  • (nodebb) in reply to colejohnson66

    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.

    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".

  • (nodebb) in reply to DocMonster

    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)

    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"?

  • (nodebb)

    .NET Core framework

    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".

Leave a comment on “Trophy Bug Hunting”

Log In or post as a guest

Replying to comment #:

« Return to Article