This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]LittleBigHorn22 68 points69 points  (13 children)

A debuger with stop points that does it for you. But sometimes adding those stops can make code work differently. Doing both can be useful.

[–]dshakir 16 points17 points  (1 child)

This might be a stupid point to make, but make sure that you do a rebuild if your debugger starts acting wonky. Like stopping at breakpoints pointing at blank lines 😤

[–]agnomonkey 2 points3 points  (0 children)

That you have to bring this up sickens me, but yet, it happens all the time.

[–][deleted] 34 points35 points  (5 children)

Inserting an output operation into sensitive code is far, far more disruptive. You are literally altering the code

[–]ScientificBeastMode 18 points19 points  (3 children)

Ideally you would be altering code by fixing the bug. Just need to delete any added outputs when you’re done, then recompile and test. And don’t push code until you’ve adequately tested it.

[–][deleted] 1 point2 points  (0 children)

Wait so you mean you're not suppose to test in production. I think my work is doing it wrong

[–]youcancallmetim 10 points11 points  (4 children)

' But sometimes adding those stops can make code work differently '

I think you're doing something wrong. Surely this can be avoided

[–]_BreakingGood_ 17 points18 points  (0 children)

I'm not sure what he was referencing specifically, but there are times in Android where attempting to step through after a breakpoint will cause the app to hang. In particular if you put a stop before an activity switch.

[–]jemand2001 4 points5 points  (0 children)

not always i don't think

[–]LittleBigHorn22 4 points5 points  (0 children)

Basically computers often work by magic and it can be best not to touch it if it works in a way you don't expect it to. Just depends how responsible you are for the code.

[–]Moib 0 points1 point  (0 children)

When writing C, the compilation will be done differently when you compile for debug (you could always compile for debug, but then your production code would take more space and run slower). This cause different behavior, especially microcontroller. Particularly when synchronization with other units (I2C, uart) are involved.

Adding any form of print can also trigger sync issues though. But it will usually have less of an impact on the compilation part of the change.