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

  • Tgape (unregistered) in reply to PotatoEngineer

    Um, really?

    git log --patch --graph branch list -- file_I_want_to_check_on

    To be clear, git log --graph doesn't really work that well in this case. It only shows branches that have updated the file in question, so you don't see the full glory (or horror, depending on ones perspective) of the branches in the project. But it does at least distinguish between the different branches that do update this file, which can be really helpful when the output otherwise shows what appears to be the same change multiple times in quick succession and stuff like that.

    I recognize that you didn't explicitly ask for the --patch option, but at least with some of the codevelopers I've had, commit messages may not be all that helpful.

    Instead of asking for specific branches, you can ask for --all. That tends to be a lot of output, but may be what you want/need. You can ask for --reflog to be able to see versions in branches that you once worked on that aren't in the repo anymore but have not yet been pruned. Unfortunately, there is no option to se all the branches that your coworkers have worked on that aren't in the repo; you simply don't have that data at your disposal (unless you share a developer machine with them and have root on said machine, in which case a --reflog in their repos will show their nearly forgotten misdeeds. Of course.)

    man git log

    has a lot of documentation on this stuff and a lot more that may be of interest.

  • Sam (unregistered) in reply to PotatoEngineer

    In addition to the pointers others gave you about git log, you can do "git blame -wCCCC" to have git look in more places for moved lines, which in my experience is a lot more useful. Also, if you have a fixed set of commits that you don't want in your blame outputs for any reason you can configure the "blame.ignoreRevsFile". It's useful but be careful which commits to put in there as you might confuse yourself later if you ignore non-trivial changes.

Leave a comment on “Divine Comedy”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article