Is there any advantage gained in having a proc declared in a later directory than at the beginning, like is

mob/races/human/player/Sleep()

any better than using

mob/Sleep()

There certainly can be advantages, if you want different types to respond differently to the same method. For example:

mob/human
proc/Burn()
src.health -= 5 //Ouch!

mob/human/Heat_Miser
Burn() //(No need for 'proc' since it's declared for humans)
src << "Ah, warmth!"

Another example: in one version of SpaceTug, I forgot to override Die() for ghosts. So they'd keep dying from the same causes that would kill live people, and eventually have names like "Gughunter's ghost's ghost's ghost's ghost's ghost"!

GateGuardian wrote:

But that makes it virtually pointless to have them declared later. It doesn't have any effect on performance or filesize or anything like that to have them declared later on, as opposed to just overriding them for certain things?

if mob/races/human/player/proc/Save() is only needed by the player of race human, then is there any disadvantage to just declaring it at mob/proc/Save() instead?

From what I understand, not particularly--it's just poor programming form. Organizing your code effectively (which includes putting procs/verbs only in the part of the tree where they're used) has two advantages:

1. It helps isolate problems faster. Suppose only a mob of a specific type is supposed to use a proc, and you accidentally write something that causes any mob to attempt to call that proc. If you have the proc defined under /mob, then there's a good chance that you'll never recieve any error messages--the mobs using that proc when they're not supposed to might be subtly screwing up your game in a way that's not readily visible. If, on the other hand, the proc is defined only for the mob that needs it, then any time you end up calling it by accident on a different mob type, you'll get an error on the spot--and it's very preferable when you screw up in your code that the computer tells you exactly where and why it screws up than to just follow your bad instructions and not mention anything.

2. It helps make code more portable. The less an object relies on parent procs, the easier it is to take that object, stick it into another project, and reuse it whole.