Granted, if it's pure pass-through then reusing the name is a non issue. Foo(x){foo(x);} is not confusing. Foo(x){junk; foo(x);} is.
One option is Foo(x){validateForFoo; ValidedFoo(x);}
Alternatively for private functions JunkFoo(x){junk(x); foo(x);} And replacing JunkFoo with a meaningful name if possible.
Again though, public function Foo(x) should really call internal function Bar(x) otherwise it's really easy to couple things on both sides of an interface.
If someone wants to know how to name the low-level helper which does the real work and the interface over it, we just have to take it for granted that the separation is necessary and that it makes sense for either function to have the name "displaySortedItems" or whatever.
SortGuiElement(){junk; SortUserNames(); junk;}
SortUserNames(){junk;}
vs. SortNames(){junk; sortNames() junk;}
sortNames(){junk;}
It might seem obvious and the code might be identical, but I see the second case very frequently in other peoples code.You want:
SortNames(){junk; SortNamesImpl(); junk;}
sortNames(){junk;}
or whatever: SortNamesGuts(), InternalSortNames(), DoSortNames(), LowLevelSortNames(). Anything but just flipping the case of a letter or two in the "SortNames" identifier.Amway IMO, SortNames() and Internal/Do/LowLevel/SortNames() are almost as bad because just looking at the names it's not obvious what's going on. Yes, visually they look different which helps and consistency can make things even more readable. But, even just SortNamesHappyPath() gives some idea of what's going on.
All kinds of functions everywhere validate their arguments; that doesn't deserve to be in their name.