• (nodebb)

    My verbosity setting works and it's turned off, so i didn't post a comment.

    Oh wait...

  • (nodebb)

    Ah, the classic confusion of what developer AND non-developers here when latter talk about OR :-)

  • my name (unregistered)

    "The biggest WTF is when I find out that I'm the one that did it, though." I feel you

  • Industrial Automation Engineer (unregistered)

    Can we have the old Remy back? This one reminds me too much of sunlight and happiness, while I'm stowed away here in this rathole cubicle.

  • (nodebb)

    Ever since he struck it rich with this website he just can't wipe the smile off his face. And the happy shirt is right at home on his private tropical island. ;)

  • Maia Everett (github) 
    const DEBUG_LOG = process.env.DEBUG_LOG ?? true

    Fixed?

  • (nodebb) in reply to Industrial Automation Engineer

    You can print him out, frame him and put a LED on him, so you end up with a bright corner in your private box ;-)

  • (nodebb)

    TRWTF is that they let devs push code changes without any code review.

  • Michael R (unregistered) in reply to adamantoise

    You must be new here.

  • Michael R (unregistered)

    I once worked for a big financial organisation where someone enabled verbose logging during the day on the PROD SQL server. The whole environment immediately came to a grinding halt. Now that was a fun day.

  • (nodebb) in reply to Maia Everett

    That should be fine for testing if process.env.DEBUG_LOG is defined (not null) and using true as a default.

    Though what everyone seems to have missed is that the environment variable is being set to the string false outside of the program so that will need to be checked for (unless I'm missing something about how C# or .Net treats true/false strings in env vars.)

  • Mark (unregistered)

    I admit to having an || false test in my "whether to show errors" code that I sometimes set to true and then set back. Hard to imagine forgetting to reset it or committing it to production, though.

  • Dr, Pepper (unregistered)

    When I do something like this, I add a comment immediately above it, like // DO NOT CHECK THIS IN

    hopefully, when I'm getting my PR ready, I catch this; or the code reviewer catches it.

    Another option would be to add a test that specifically checks for the code change you don't want to have committed; which fails as long as the code is broken. That way, when you run the tests, the failed test lets you know that you need to revert your change.

    Oh, wait -- those require pull requests; and code reviews; and unit tests. Never mind.

  • (nodebb) in reply to Maia Everett

    surely that should be

    const DEBUG_LOG = process.env.DEBUG_LOG ? true : false

  • (nodebb) in reply to Dr, Pepper

    Or have such flags set in a local config file that's listed in .gitignore or equivalent, so each individual user can have their own conf/prefs that won't get committed.

  • Your Name (unregistered)

    I am guilty of something like this as well. Too lazy to always to a whole upload file to SFTP to be able to download it when debugging I added shortcuts directly loading a local file. More than once it made it to QA, and they asked why it would like to open a local file on a drive they didn't even have. Sprinkled a #IF DEBUG around and things are nice again :)

  • Paul (unregistered) in reply to Dr, Pepper

    Or set the variable using conditional compilation. true when you're developing, false in release builds so it'll never be enabled in a production release.

  • (nodebb)

    Fixed it

    const DEBUG_LOG = process.env.DEBUG_LOG || true && FILE_NOT_FOUND
  • (nodebb) in reply to gordonfish

    Or have such flags set in a local config file that's listed in .gitignore or equivalent, so each individual user can have their own conf/prefs that won't get committed.

    Personally, I've taken to using a pre-push script for that. Any debug statement I write contains the substring "DBG:", so my pre-push script checks the code for that string (excluding comments).

    Doesn't mean other code doesn't end up getting pushed accidentally.

    Also, since this is Fortran, I am sometimes fighting with language limitations with unexpected results. We have a "TO_STRING" macro, that is used in debug statements, like our "ASSERT" macro, but due to a strange warning message I noticed, that

    ASSERT(INDEX(foo, "*")>0

    expands to something that contains

    PRINT *, "INDEX(foo, "*")>0"

    and you can probably see where that one goes wrong.

    I still don't understand why the warning was about a Hollerith constant though. And now upon reading up what that actually means (without just googling for the whole warning), it turns out to be a throw-back to Fortran 66 not having a character type. Oi...

Leave a comment on “On the Log, Forever”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article