• vala@lemmy.dbzer0.com
    8·
    1 day ago

    As someone who knows how to use a debugger, I can say for sure that log debugging is fine and often my first approach. If you have a good mental model of the code and the issue, it’s usually just 1-2 logs to solve the problem.

    • silasmariner@programming.dev
      6·
      1 day ago

      This is the way Although I also like:
      File 1:
      print(0.1)
      print(0.2)
      File 2:
      print(1.1)
      print(1.2)
      …

      Minimal c+p+e effort

  • 2deck@lemmy.world
    33·
    2 days ago

    To me logging combined with a quick compilation has a good flow to it. Causes you to consider what you want to see and doesn’t change the workflow if multiple stacks are involved.

  • madcaesar@lemmy.world
    2·
    1 day ago

    Honestly I use debugger when I have to go deep into some library’s bullshit code. My stuff should be stable clean and understandable enough to quickly see what’s happening with console log.

    If I were to find myself needing debugger all the time with breakpoints and all this shit, it means shits has gone sideways and we need to back up and re-evaluate the code.

    • Victor@lemmy.world
      1·
      13 hours ago

      Not sure why you would say that. An alert() does not show you where in the code the alert was called from. A console log would show you.

  • NotSteve_@piefed.caEnglish
    112·
    2 days ago

    It drives me crazy that half my coworkers do this, including a senior dev. I’ll be on a call trying to help debug something and it makes it so difficult not being able to set a breakpoint

    • andyburke@fedia.io
      29·
      2 days ago

      I console.dir and debugger; and breakpoint all day. You are allowed to mix your strategies.

        • Omgpwnies@lemmy.worldEnglish
          2·
          1 day ago

          and the one that keeps getting slept on for some reason, watch breakpoints - stop when foo is changed. Great for figuring out what is screwing with your data when foo mysteriously changes

    • RheumatoidArthritis@mander.xyz
      6·
      2 days ago

      I used to do debuggers until I started doing embedded and dipped my feet in multithreading (2 different projects). After many hours lost because the debugger straight lied to me about which line of code has been executed, a colleague suggested that I just do a printf like a filthy beginner. And 🤩it worked🤩 and I never went back to the unreliable world of debuggers. Even though now I’m mostly working with single-threaded python scripts.

    • Quantenteilchen@discuss.tchncs.de
      41·
      2 days ago

      There are literally university courses which confidently state “Console logging is far more used and better so we won’t talk about a debugger here”!

      Like sure, it’s very likely to be used far more, but that doesn’t mean you shouldn’t at least offer some courses or modules about proper use of a debugger…

  • RustyNova@lemmy.world
    2·
    2 days ago

    I am guilty of this but for a different reason: setting up debugging for clis in rust is hard

    I love the debugger. I use it all the time I can. But when debugging cli it’s a pain as you need to go back in the launch.json file, remake the argument list, then come back to run debug, find out why tf it doesn’t find cargo when it’s the PATH… again, then actually debug.

    • Victor@lemmy.world
      1·
      13 hours ago

      I don’t feel at all guilty of doing this. Whatever works. Usually nothing is so complicated that I need to debug properly, instead of just inspecting some value along the way.

      In fact, if it gets the bug resolved, it is—effectively—debugging.

  • DrDystopia@lemy.lol
    61·
    2 days ago

    It’s like the real life kraken, I’ve never seen it but the name causes dread.

    • kubica@fedia.io
      21·
      2 days ago

      This is what peak performance looks like:

      console.log("before dothething");
let r = dothething();
console.log("after dothething");
console.log(r);