• (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

    Of course you sometimes need to clean things up--and the clueless one isn't doing so.

    No you don't, you just have to do all your test inside a transaction and then do a ROLLBACK or exit the shell and the db does the cleanup for you

    Oh you don't have transactions you say - go use a better database (was one of the reasons I selected Postgres over mySQL some 20 years ago)

  • mihi (unregistered)

    Am I the only one old enough to remember that subqueries were not supported before MySQL 4.1, and correlated subqueries were not supported before MySQL 8.x? There were various workarounds...

  • (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.)

  • (nodebb)

    log_bin_trust_function_creators being set to 1 is definitely a WTF. Functions (unlike stored procedures) are meant to be deterministic and "safe" (in the SQL sense). This is basically turning off those protections.

  • Farrah (unregistered) in reply to PotatoEngineer

    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"

    git log file.cpp will only show commits that touch particular file. -L will limit to particular range of lines, -S and -G will grep the diff (-i will make it case-insensitive, useful for comments). I also find --since and --after useful to search specific date range.

  • Craig (unregistered)

    git blame is great at telling you how something came to be in a file, and completely useless at telling you how something came to not be in a file.

Leave a comment on “Divine Comedy”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article