Is it considered poor form to do something like this:
shoeSize is the method, shoeSize is the variable that is returned within the method.
I know there are other ways to do this particular example - and I am using one of them in the code that made me think of this, but in general, does one avoid having a method named similarly to one of it's internal variables?
However, this convention isn't an absolute requirement, and there are many classes in the standard libraries that don't follow it - size() being one very common example. I think it's only a problem if you're using some reflection-based framework that assumes getters and setters will always follow the standard naming convention. In many classes this will not be an issue. In my experience there's no real problem if a method name matches a field name - it's always possible to tell which one you're talking about, based on whether or not there's a () after. (And in many cases they would have the same effect anyway.)
What I think would be a bad idea, would be if a method and field had the same name but were actually unrelated. If I see a field named size, and a method named size(), I'm probably going to expect that the definition of size() is
If on the other hand, it's
then I think that's a potential source of confusion; I wouldn't recommend that.