64
Sundeep
41d

Most of the times 😂

Comments
  • 9
    A hammer can only get so big until you can barely lift it to pound in the tiny nail
  • 9
    Setting breakpoints takes too much time and effort.... Much easier to add 8273827371 print statements like "sugma" "lol" "wtf" "lick ma balls" /s
  • 2
    damn how far have we come ... year 2020 and devs still do this?
  • 8
    @mojo2012 If it does the job, then it does the job, no?
  • 0
    Frankly I don't think debugger will help a lot to debug concurrency issues :) printf/echo/sout is the go-to technique when you need to project all the activity on a single timeline.

    Debugger is somewhat useful, but it takes a split second to synchronize before blocking all the threads, which has hidden from me lots of critical section handling errors. printf is really irreplaceable here ;)
  • 0
    Only two reasons to do that in my opinion.
    1. Environment doesn't support debugger or has to be set up yet.
    2. Stepping trough takes more time than analyzing output (looping trough a lot of data or the result is going through a large call stack that has no bugs). Sometimes you can add some code to work around this issue though: if data == ... {breakpoint}.

    Being able to use a debugger saves so much time mainly because you can see all the state (often shows the problem or the direction to look in) greatly prefer it over printing.
  • 0
    print("A") to print("Z")
    Same for 0 to 9.
    Sometimes print("AAA2") etc.
    And sometimes print("Loop"), print(data), print("function call successfully executed")

    I guess I'm too lazy to set up the proper debugger environment.
  • 0
    damn exactly today i had a weird issue that only showed up on CI and on no other machine - repeatedly.
    yep I admit it, I added log output 😂
  • 0
    @theuser The perfect excuse for shit stuff like pasta coding
  • 0
    There's VS Code extension that can manage and turn on/off debugging print lines. I don't know the name though.
Add Comment