I agree with the sentiment that you should keep constants as local as possible. If you're using constants
as some part of implementation detail, there's no reason why a client of that code should know about
those constants. It should be possible to change the implementation without changing the outward
functionality. If you make your constants at the class level so that basically everyone knows what you're
using, it becomes much harder to be able to change implementation details because a client may have
used your specific implementation details in their usage.
It's the same reason why we have various access modifiers. It's no different from saying "Hey I'm just going
to go and make all my methods public so it's easier to work with this class." In both cases, you're blatantly
violating encapsulation and you're exposing way too much of yourself.
Think to yourself: Do you use different access levels for fields and functions? Do you use different scopes
and access levels for your variables you use? Constants are no different and should be treated the same.*
Unless you have a good reason to expose a constant, it should be hidden away in whatever function or
scope it's required in.
In these cases, 'as close as possible' would BE a magic number.
What if you use it in multiple places? Or if you need to change it at some later point? Imagine you used magic
constants in just two places in your code. Then you change it and forgot to change the other. Now the program
could crash, or even worse, run and spit out the wrong results.
Don't forget that by using a constant, you can make your code document itself without requiring an explicit comment
in the middle of the code. Placing that constant at the method level is in no way similar to using magic constants, at all.
Edit: Just thought of something else. When I say client in the above post, I'm talking about ANYONE who calls your code.
That could be you within your own application, or someone else reusing your code for something.