How to make sure that you don't have problems: Learn about floating-point arithmetic problems, or hire someone who does, or use some common sense.
The first problem is precision. In many languages you have "float" and "double" (double standing for "double precision"), and in many cases "float" gives you about 7 digits precision, while double gives you 15. Common sense is that if you have a situation where precision might be a problem, 15 digits is an awful lot better than 7 digits. In many slightly problematic situations, using "double" means you get away with it, and "float" means you don't. Let's say a company's market caps is 700 billion dollars. Represent this in float, and the lowest bit is $65536. Represent it using double, and the lowest bit is about 0.012 cents. So unless you really, really know what you are doing, you use double, not float.
The second problem is more a matter of principle. If you do two different calculations that should give the same result, they often don't because of rounding errors. Two result that should be equal will be "almost equal". If two results are close together, then the real values might be equal. Or they might be not. You need to keep that in mind and should write and use functions that say "x is definitely greater than y" or "x is definitely less than y" or "x and y might be equal".
This problem gets a lot worse if you use rounding, for example "round x down to the nearest integer". If you multiply 120 * 0.05, the result should be 6, but what you get is "some number very close to 6". If you then "round down to the nearest integer", that "number very close to 6" might be "slightly less than 6" and get rounded to 5. And note that it doesn't matter how much precision you have. Doesn't matter how close to 6 your result is, as long as it is less than 6.
And third, some problems are difficult. That means there is no quick and easy rule. If your compiler supports "long double" with more precision you can use "long double" and see if it makes a difference. If it makes no difference, then either you are Ok, or you have a real tricky problem. If it makes the kind of difference that you would expect (like a change at the 12th decimal) then you are likely alright. If it really changes your results, then you have a problem. Ask for help.
distanceTraveled(startVel, duration, acceleration)would be tested.