And how exactly is this better than typing out the full file path?
You have to switch over to that folder to find what your parent is and then switch back to whatever other file and try to find what you're looking for.
Instead of knowing immediately upon looking at where the issue is, and going directly to the parent's code from there.

Everyone is arguing with MrPerson but has yet to give an actual reason how parent_type is better in any way then typing the absolute path.

In one file, seeing:

human
parent_type = carbon

In another, having to find::

carbon
parent_type = living

In yet another, having to find:

living
parent_type = mob


VS. knowing immediately in every file related to humans that the define is:

mob/living/carbon/human
In response to Intigracy
It's a matter of personal preference. The issue is more that people are concerned about people using it. There is no reason to do it, or not to do it.
Except it's arguably better for organizational skills, which is what this thread is about.

You have yet to give a single point saying or proving otherwise.
parent_type is not something that discourages organization. If overused, things can get disorganized. As I said, it is a matter of personal preference. I don't plan on handing out my sources to anyone, and I can understand what I wrote just fine and because I have my files organized well, I do not experience any problems.

parent_type is not an organizational issue, it is merely something that can cause an issue if you don't have good organization. Does that make sense to you?
Each has its merits, and neither is inherently better than the other, so the premises under which you two are arguing will not get this thread very far.

Anyways, like others have said, the code within my projects' files usually adhere to its respective file names, such as code pertaining to movement will have a file called movement.dm and so on.
I tend to make my code match my object tree.

Apart from that, I always prefix full types ahead of any proc definitions (so it's easy to find the actual proc definition/overridden implementation)
Double-clicking nodes in the object tree takes you to one of the places in the code where that node is defined. It's only one place and it's not guaranteed to be the definition, as opposed to an override. I think it'd be nice if repeatedly double-clicking it would loop through all of them, or something.
Yeah, which is rather annoying; hence why I make my code match the object tree. Means I can sidestep that issue.
Page: 1 2