The formula most people use is wrong for their actual problem
You take the two shorter sides, square them, add them, and take the square root. That is the Pythagorean theorem and it is what you learned in middle school geometry. It works perfectly in a textbook. It does not always work perfectly when you are actually writing code or doing engineering calculations. The standard approach uses c = sqrt(a² + b²). In most programming languages that translates to something like Math.sqrt(a*a + b*b) or pow(c, 0.5) where c is the sum of the squares. If you are using Python you would write math.hypot(a, b). If you are using Excel the function is =SQRT(A2^2+B2^2). The result is always the length of the side opposite the right angle. I spent about six months debugging a simulation where the hypotenuse calculation kept returning NaN values. The input data came from sensor readings that included occasional zeros and near-zero values for one leg of the triangle. When both legs were very small, the squared values underflowed to zero in IEEE 754 floating point representation and the square root of zero is fine, but the ratio calculations downstream exploded because they divided by what the system treated as zero. I ended up switching to math.hypot instead of the manual square root approach because Python's implementation checks for overflow and underflow before squaring the inputs. That single change fixed the entire failure path.
Here is a concrete example with actual numbers so you can see the arithmetic. Let leg a equal 3 and leg b equal 4. Square both to get 9 and 16. Add them to get 25. Take the square root and you get 5. That is a 3-4-5 right triangle and it is probably the most common example you will ever see because the numbers are clean. Now try something messier. Leg a equals 7.3 and leg b equals 12.8. Squared those are 53.29 and 163.84. The sum is 217.13. The square root is approximately 14.7357. There is nothing special about those numbers. They just come up when you are working with real measurements that are not rounded to whole numbers. There is a significant pitfall most people do not think about until it costs them time. When one leg is enormously larger than the other, squaring the larger value can cause floating point overflow before the addition even happens. Say leg a is 1e200 and leg b is 1. Squaring a gives you 1e400 which exceeds the maximum finite value in double precision floating point. The result is infinity and adding anything to infinity still gives infinity. The square root of infinity is infinity. Your answer is completely wrong because the actual hypotenuse should be basically 1e200, not infinity. The workaround is to use a scaled computation or a library function that handles this internally. Functions like C's hypot() or Python's math.hypot() compute the result without the intermediate overflow by factoring out the largest magnitude before squaring.
Another thing beginners consistently get wrong is assuming the theorem applies to any triangle. It only applies to right triangles where one angle is exactly 90 degrees. If you have an acute or obtuse triangle and you plug the side lengths into this formula you will get a number that has no meaningful relationship to any actual side of that triangle. The generalized version for non-right triangles is the law of cosines, which is c² = a² + b² - 2ab*cos(C). That extra cosine term is what makes the difference and most people skip straight to it without understanding why the simple version fails outside its domain. The main limitation of the Pythagorean approach is that it requires you to know the right angle exists beforehand and that your two known sides are actually the legs adjacent to that right angle. If you are given a hypotenuse and one leg and need to find the other leg, you rearrange to a = sqrt(c² - b²). This introduces a different failure mode: if your measured hypotenuse is slightly smaller than one of the legs due to measurement error or rounding, the value under the square root becomes negative and you get a NaN. In practice this happens more often than you might expect when working with real-world data from instruments that have tolerance bands. The fix is to validate your inputs before running the calculation and clamp or flag cases where the hypotenuse does not exceed both legs. If you need to compute this repeatedly in a batch or in a performance-sensitive loop, avoid calling a general-purpose square root function and a separate squaring function separately. Use the dedicated hypotenuse function that your language or platform provides. It is usually implemented with overflow protection built in and it tends to be slightly faster because the internal implementation can make assumptions about the input range.
Get the Full Details
When the formula breaks down
Coordinate geometry introduces another practical scenario. If you are given two points on a plane and need the distance between them, that distance is literally a hypotenuse calculation where the differences in x and y serve as the two legs. Point A at (2, 5) and point B at (8, 10). The horizontal difference is 6 and the vertical difference is 5. The distance is sqrt(36 + 25) which equals sqrt(61) or about 7.81. This is the same formula wearing a different hat and it is worth recognizing because people sometimes treat these as unrelated problems when they are not. The one situation where I would not reach for this at all is when you are working in non-Euclidean space. On a sphere the shortest distance between two points follows a great circle path and the Pythagorean theorem gives you a result that is only approximately correct for very small distances. If you are doing anything with GPS coordinates or large-scale surveying the error from using plain Pythagoras becomes significant. You would use the haversine formula orVincenty's formulas instead. The difference between the two methods becomes noticeable at distances above roughly 10 kilometers depending on your precision requirements. I have been doing this long enough to know that the simplest version of a formula is not always the right one to use in practice. The math is correct. The issue is almost always the context around it. Check your inputs, use the right function for your language, and verify that the triangle you are dealing with actually has a right angle before you start squaring things.
