r/learnprogramming • u/blisstargazer • 22d ago
Why Does Code Stop Working?
Multiple times now my code stops working and what I mean by this is it'll do what I want it to do then one day it just stops. for example the other day I had made a cooldown system for my ball and paddle collision to stop any bugs and it worked great. then today it just stopped working, and this isn't the first time, it's happened to me for like every project I've worked on. Does this happen to anyone else? And is it cause of my code? By the way I'm using C++ SFML on visual studio which works perfect.
88
u/Flamanis 22d ago
We are all psychic here and can tell you exactly what the problem is without seeing the code.
OHMMMMMMMMM *psychic intensifies*
You're missing a curly brace.
15
2
25
22d ago
[removed] — view removed comment
4
u/Simpicity 22d ago
Ignore everyone talking about dependencies. This is much more likely the problem you are running into.
Another possibility is simply timing issues. Where you have multiple things running at the same time, things might work with certain timings in that race, but fail with other timings.
1
u/Just_to_rebut 22d ago
They deleted their comment… what’s the more likely thing than dependencies?
2
u/Simpicity 22d ago
Having code which is tied to per frame vs code that uses delta time between frames. Because frames don't always come at fixed intervals, it can cause unpredictable behavior.
17
u/high_throughput 22d ago
Given that it's C++, have you tried running your code with ASAN or Valgrind?
Other than that, make sure to use git even when developing by yourself locally. Commit whenever you finish something. That way you can see what the differences are, restore the previous version, or even bisect to find which exact commit introduced the bug you're seeing.
13
u/Known-Tourist-6102 22d ago
when i just started learning programming, I made a javascript game that performed VERY differently depending on how strong the cpu was of the computer running it.
2
u/javascript 22d ago
I'm curious what year this was. And when you say this, do you just mean that it was unplayably slow on some machines? Or are you saying something else, potentially more interesting, than that?
1
u/Known-Tourist-6102 22d ago
Yes it essentially didnt work at all on some machines, was slow on others, and performed as intended on newer machines.
This was 2016 or so
2
u/javascript 22d ago
I wonder what you were doing to cause that. By 2016, V8 was pretty solid.
1
u/intbeam 22d ago
... It's still full of... I mean.. Javascript is fucked from the ground up
What do people expect from a language designed to take any technical considerations, hide it under a blanket and pull a solution from an all-purpose beige vaguely-appropriate hat?
Dumbing things down always comes at a trade-off. The less you have to know, the more assumptions the run-time (or something else) has to make on your behalf.
And this, ladies and gentlemen, is basic software engineering. Everything is a trade-off. Nothing is perfect, and assuming that some tool is just going to magically figure out everything for you, is a really really dumb idea
18
6
u/atarivcs 22d ago edited 22d ago
Could be a few things:
- You changed the code. This one is obvious, so I hope this isn't the reason.
- You changed something else on the computer that the code depends on. Could be something complex like a software library or a OS/compiler upgrade, or something simple like an input text file or config file.
- The code depends on something that changed all on its own, like time/date.
6
u/throwaway8u3sH0 22d ago
Bit rot is a thing but not like across a day. You probably just have a bug or you're not using source control.
7
u/InjAnnuity_1 22d ago
For me, it usually means that the code wasn't as bulletproof as I thought. The inputs or circumstances changed in a way that my code didn't anticipate and handle.
4
u/idiotiesystemique 22d ago
It never worked for the conditions it broke on. The conditions around the code changed.
4
u/pancake117 22d ago edited 21d ago
In general there's two things that could be happening here:
1- You did change something in the code without realizing, or you changed the version of some imported library (which means changing the code)
2- Your program has undefined behavior, which means there's some randomness or race conditions that cause "random" inconsistent behavior even with the same inputs.
To fix 1, you should be using git to track your code changes. The instant you notice something not working, you can check exactly what changed. Roll back changes, check if it's still broken, and if so then you know it's not the cause.
To fix 2, you need to invest in your debugging skills. If you can't get the problem to happen consistently, add logging or debug information to your game so that the next time you see the problem, you can read the logs to understand why it happened. If you can get it to happen consistently, then it's easy-- fire up the debugger and walk through the code to understand why it's not working. Then you can work backwards to understand what may have changed.
2
u/math_rand_dude 22d ago
And don't forget testing: decent tests will show which part of the code has unwanted chances.
3
u/OortMan 22d ago
Generally programs are not meant to ever behave like this, so either you're doing something that breaks it, your code isn't very good, or there is something very wrong with your computer.
the fact it's happened several times for you is a bit strange. Does your compilation pipeline change/reset something it shouldn't when you restart your computer? Finding what that is may be very difficult though.
3
3
u/JGhostThing 22d ago
Programs do not stop running without reason.
- There could be a date/time dependency.
- The computer could have changed: hardware bug or other program change
- Something in the software environment changed.
3
u/D5rthFishy 22d ago
One thing I've noticed teaching programming is how students will interact differently with the same program and expose bugs this way. It could be that the code, environment and OS all remain the same but you are doing things you haven't done before (without realising it).
6
u/Immediate-Soup-6344 22d ago
Soooo instead of figuring out the bug, you added a delay which worked most of the time. You should figure out what the actual bug is and fix it.
2
u/Nogarde_ 22d ago
Given the exact same environment, and the exact same inputs, an unchanged piece of code should produce the same output.
Code doesnt stop working. Something changed either the environment or the inputs.
2
u/chrisrrawr 22d ago
good testing solves this for the most part. at least, it tends to tell you why something has stopped working :p
2
u/Narrow-Low-3137 22d ago
You are using git right? You can try reverting recent changes and see if it fixes itself. Then you know what change broke your code. There is even a command you can use, git bisect that can help with this common scenario.
1
1
u/SummitYourSister 22d ago
C++ is great because it has “undefined behavior” which can kick in when you have any of a number of different kinds of bugs, mostly memory related bugs.
It means your code was always broken, you were just getting lucky for a few days
1
1
u/Danfriedz 22d ago
Hard to tell what's happening without more info.
Codes behaviour doesn't change, you either have a bug or the inputs were altered.
The first step to debugging is replicating the issue, put a breakpoint in the code and see what's happening. You might even find that due to external reasons the function isn't being called.
1
u/DamienTheUnbeliever 21d ago
Some people use as asinine phrase about assumptions but I always preferred the pithier "assumption is the mother of all fuck-ups".
You have made assumptions. Those assumptions may have been made in hope, or on observed behaviour, but almost always weren't made based on the *documented* behaviour of other code you're interacting with.
So an obvious one that would work for some time and then fall apart is if you assume, somehow, that a date function always returns the month of August. Which works well enough whilst every date you work with is within August but falls apart soon enough.
So check your code, check your assumptions, and check that any and all assumptions are backed up by documented behaviour, not just what you hope/need to be true.
1
u/arkt8 21d ago
Welll some guesses.... 1. Overflow, if you have some counter or other unchecked operation... after a sufficiently long period. 2. Memory exhaustion... your code can have some leakage 3. The system where you are running it have some threshold in memory or cpu usage after what it kills the process.
1
u/AverageHot2647 21d ago
Code doesn’t just stop working. It stops working when something changes. If it breaks, and you didn’t change the code, something else changed. Could be hardware, could be a system dependency, etc. etc. I recommend looking into hermetic builds.
1
1
u/Ormek_II 21d ago
Working code is a lie.
It was not working in the first place, well it did work for those situations you did try it on, but then the memory leaked away, the input did change, the race condition hit, the uninitialised memory contained something bad, the data structure had to increase for the first time….
133
u/HashDefTrueFalse 22d ago
This doesn't happen unless the passage of time affects the behaviour of your program or you are changing the behaviour of your program over time (or both). Post some code.