I try to split my project into as many files as I deem necessary to keep things organized and easy to find. For example, I will have seperate files to handle Stats, HUDs, Combat, Movement and so on.

When it comes to documenting my programming, I like to keep things simple. I see no need to have a lengthy and detailed explaination for a "Stat" datum as everything will be obvious from just looking at it. A proc with a lot of algorithms on the other hand, I will comment in great detail. On more than one occassion I have gone back to a 4 year old project and not been able to make heads or tails of my work.

Keeping your files tidy and organized, like many other things in life, is just a good habit to get into. Document your programming as much as you deem necessary so that one can understand what it does and how it does it.

Some would go as far as saying that a complete stranger should be able to look at your project for the first time and understand what everything does by reading it's documentation. While I personally find this a good habit if you intend on working with/for other programmers, I don't think a hobbyist needs to be so anal.

I keep all my files extremely tidy and organized. I will use folders inside of folders inside of folders in some cases.

I keep my files extremely relevant to what they are. If for example I have a folder called Player, all the files in it handle the players. A file called stats might handle how player stats work, another file called loading will handle how a player saves/loads and so on.
I will never have massive thousand line long files for anything.

I comment things. I'm not great at this, but everytime I add something I always add a short description about what it does and how to use it.

People might tell you this a bad idea (and it might be). But I make the name of my variables and procs extremely obvious instead of using weird naming conventions.
My function for attacking is called "Attack", and the one for calculating damage is called CalculateDamage and so on.

I basically do these three things, and right now I can handle a project that's exceeded 25,000+ lines of code with enough precision that I know what each and every file, object, proc and variable in it does and where they can be found. I have a decent memory so that probably helps.

I always keep my file organized. I tend to sometime overdo it. I only recently started commenting more often on what I program(a week ago), unfortunately. Never realizing how easier it is.

I try to make it extremely easy to comprehend. This is mostly why I always work as a "leader", because if I change the way I want the source to be organized people just might end up confused. I take my time(often hours) to write guides for my projects once it is finished. I do this to help any future project leader or if I haven't work in X source for over years.

I never comment too much! I often use the desc setting to reference myself for each individual verbs I programmed.

I always make my source look complicated but readable to a decent programmer. The reason why do this is because it's so that if somebody gets a hand of a project, the person would have to learn DM language properly.

The reason I do this is because when I joined BYOND, a month ago, I found out this rip Naruto source. It was extremely easy to learn from it as I had read few chapters of the Dream Maker. I then saw people saying how it gives bad habit to learn from rips. I found a source called Naruto Unforgiven.. which looked completely different and undecipherable. I then understood I had to learn DM the proper way(I honestly have no idea if this just made sense).

I think one day you'll come back and look at this post and see some things that will make you remember what it was like to be a newbie to programming. Haha.

As for me, I have gone through many different "phases" of documentation and organization. I've finally settled on something that works for me. I don't like having tons of folders, because I'm pretty lazy. I have one "Code" folder that contains all of my files, but every file is named for what is specifically in it. For example:


As for documentation, when things get complicated, I make sure to give a little comment about what the purpose is. I do this mainly to make things easier on myself whenever I go back and look at it. Examples of this are when I have to do some statements and I use more complex methods (Like comparing many different factors in an if statement via && and ||, or doing a lot of number or text manipulation in one line with copytext(), findtext(), max(), min(), etc). In general though, I work in bursts mostly, so I don't like wasting time writing about what I'm going to make rather than making it. I go back later and document the details.

Its not something that everyone does, but it works for me.

You can see the epitome of horrible organization and poor documentation in the Hazordhu source.

Forum_account has a few relevant articles. Find them in the Resource Repository.

I always define proc and variables so that their object is absolute while they are tabbed. I define new datums often too with combination of parenting.

Why is it stupid?

It's perfect for me.

parent_type is pretty useful, actually.

It feels like you're whining about "what-ifs" that are all results of poor documentation, not the use of parent_type.

I always create a folder where I have defined parent_types for each new instance. These "header files" I start with "_" so they always appear at the top of the folder.

This code is from my current project:

As you can see I try not to modify default types like /mob so I can always create new derivations without having defined vars and proc which I wouldn't be use anyway.

You may notice curved brackets and semicolons. I rewrite the code using these when this feature was successfully tested and debugged and it is information for me that this piece of code is healthy.