ID:75253
 
So after years and years of programming games on BYOND, I've been through almost every kind of organizational system to keep my code organized, and I've never came up with one solid system. The other day I decided to sit down and think of how I could organize my code in such a way where I can easily access all my systems and objects and procedures in a non-bulky and clean way. I came up with something that I just had to share with you guys, out of all the years I've spent programming, this is probably the best method I have used/created. Please, feel free to share your organizational methods, as I would be very interested in seeing other people's systems.
So basically it goes like this:
defines.dm              //all global variables and #defines
+datums //folder
-defines.dm //in this file, simply define all the datum paths, variables and proc \
names, nothing else

//create a sub folder of the name of your datum, some examples:
+missions
//here define each procedure as a new .dm file
-new().dm
-process().dm
+defines //ive seperated the code into two main categories. defines and procedures
//under the defines, you simply NAME procedure names and variables and paths
//under procs you actually write the procedure for that type
-areas.dm
-atoms.dm
-turfs.dm
//for types that have a lot of sub-types, like mob and obj for example, make a folder
+mobs
//define each sub-type of mob as a new .dm
-mob.dm
-npc.dm
//if you wanted to go more in-depth:
-headmaster.dm
-first_mission_guy.dm
+obj
-items.dm //a definition file of the item path and its variables and procedure NAMES
+equipment
//now if you have a lot of equipment you can name each .dm file as a piece of equipment
-armored_vest.dm
//or if you want everything in one .dm because your only defining them anyways,
-equipment.dm
//and simply define each type with their own variables

//and do the same with these
+gadget
+weapon

+procs //this is where your actually going to put the procedures
//for each type, make a folder

//now for each folder, enter the procedure as its own .dm file
+area
+mob

-login().dm
-die().dm
-process().dm

//you can go more in-depth by adding sub-folders for each sub-type of mob
+npc
+player
//etc..

//same idea throughout
+obj
+turf

//now here is where all the procedures that don't belong to anything go
//for example a name parser
+procs
name_parse().dm
//or a round starter
start_round().dm

And thats pretty much it. I just wanted to share this with you guys, it may help some of you. It did me!
http://www.byond.com/members/Tiberath/files/images/ code_organised.png

(Underscores on files of particular importance.)
I've never been one for an incredible level of organization (especially not involving folders... I don't even store my icons in a subfolder), but I do have a sort-of system...

I break my code up into logical sections, and name each file according to its primary subject or function, in the form of [atom type]_[subtype].dm

So for instance, Murder Mansion has the following:

mob_player.dm
mob_AI.dm
obj_actionobjects.dm
obj_gamemaphandlers.dm
obj_HUD.dm
turf_architectural.dm
turf_interactive.dm

And then there are some other files, like world-level procs, general atom-level code and such that get grouped together by the names of 'sys_[whatever].dm'

I also have a general practice of copying included libraries into a new .dm file within each project (I tend to tinker with them based on each project, and I obviously don't want to be messing with the original copy, so each project that a library goes into gets its own copy) and these are grouped by the naming convention of 'lib_[libraryname].dm'
A few months ago I started breaking my code into relevant folders. Perhaps one folder for world-setup code, one folder for interface code, one folder for graphics, one folder for object definitions, etc... That way you only need to have the list of code files that you're actually working with in immediate view. If you want to open a different section of files, you close one folder and open another. Or you can just open all the folders and it still displays the files neatly divided into sections.

The only projects that I've actually done that with are Tomb Explorer and Tomb Editor, but it worked out fairly well.

I also use underscores the same way that Tiberath does.