• (nodebb)

    "Code should be clear and explain what it does, comments should explain why it does that."

    One legitimate use of dead code is when future users will be tempted to use a certain approach, and need to be explicitly warned why that approach is a bad idea. BTDT from both sides.

  • ThunderBird (unregistered)

    I have one I made in our codebase too:

    // REMINDER: CloudFlare will fail if it ever receives the header below.
// Deny all client requests to proxy it!
// "CF-Connecting-IP",

    I keep it in there because if this ever comes up again, I want this warning to be front-and-center for my devs after what I did. I don't care that Git remembers, by the time this hits Git, it's too late.

  • Argle (unregistered) in reply to dpm

    One legitimate use of dead code is when future users will be tempted to use a certain approach, and need to be explicitly warned why that approach is a bad idea. BTDT from both sides.

    Your comment made me chuckle. The following is from code I wrote recently:

             * The following dead code needs to be retained because someday, some future programmer is going
         * to conclude that it's the better way to manage the many possible interop calls.```
  • Loren Pechtel (unregistered)

    Add me to those who believe that on occasion commented out defective code is the best way to establish that obvious approach does not work.

    And I have no problem with most of the comments here. There's somebody else dealing with this stuff that doesn't understand enough and these are warnings to said person. Who hasn't pasted SQL into the control panel to figure out just what's going wrong? Of course you sometimes need to clean things up--and the clueless one isn't doing so.

  • Yazeran (unregistered) in reply to Loren Pechtel
    Comment held for moderation.
  • mihi (unregistered)
    Comment held for moderation.
  • (nodebb) in reply to ThunderBird

    When I see people say "the Git logs will have the comments you need," I wonder what their commit logs look like. Because once you have enough code (and edits) committed, "git blame" no longer has the commit with the reason why you did that thing, and now you're trawling through a giant list of all commits that happen to include the file, hoping against hope that the reason is a) actually in the logs and b) recent enough to be relevant to the current code.

    Of course, what this really means is that I don't know Git well enough, and I'm sure there's some magic command I can use to get "only commits that include this file and not too many others" so I can look through the relevant commits and not have to filter out the "repo-wide linting/spacing/etc" commits.

    (I'm pretty good about updating the "why/how" comments when the "why/how" changes. Usually. My fellow devs seem to be much worse about it.)

Leave a comment on “Divine Comedy”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article