ID:591242
 
As the length amount of your code increases, what is the best way to keep everything organized? What ways do you use to find things in your code without searching through irrelevant code? How do you kep up with all of your variables? etc....
Well methods of organization vary from person to person but personally, I try to keep related things in their own .dm file. For example, anything pertaining to combat would go in _Combat.dm. Also, whitespace. Whitespace. Whitespace.
I use a similar method to Kumorii whenever I am working in DM. However, in addition to that I also like to use something like //--[section name here]--------------------------------------------------------------------------------------------// in each file wherever I feel is necessary to separate sections. Sections could be whatever you like. Procs, verbs, vars, anything that makes sense to you and doesn't cause any programming problems. The method really does vary, though. To each their own.
Instead of putting 40 pieces of code in one .dm file. Make a folder and put them in seperate files within the folder. So you can just pick the one you are after. Write yourself a litte note at the top of each page explaining where all linked code is kept in your game folder.

That is what I do anyway.
Raruno wrote:
As the length amount of your code increases, what is the best way to keep everything organized? What ways do you use to find things in your code without searching through irrelevant code? How do you kep up with all of your variables? etc....

That's the question that most of my "programming tips" articles answer in one way or another, some more directly than others. Here's a list of all the articles:

Programming Tips #1 - If Statements
Programming Tips #2 - Making Progress
Programming Tips #3 - Design
Programming Tips #4 - Datums
Programming Tips #5 - Organization
Programming Tips #6 - Procs & Organizing Code
Programming Tips #7 - Comments and Whitespace
Programming Tips #8 - Loops and Ifs
Programming Tips #9 - The Map Editor
Programming Tips #10 - Variable Names
Programming Tips #11 - Bringing it Together
Programming Tips #12 - Arguments

While it's good to organize your files so it's easy to find things, you should aim to minimize the number of times you need to find something. If you have a proc for creating an on-screen damage effect and it takes 12 parameters, you'll probably have to look it up a lot to remember what all the parameters are. While it'd be convenient to put that proc in on-screen-damage.dm so you can easily find it, the best solution is to change the proc so it's not so difficult to remember how it's used and you don't have to look it up as often. Though, if you want to make changes to that proc you can't avoid having to find where it is.

Here are some things I do:

1. Follow almost all of the advice in the articles I linked to above, especially #5 - Organization (the naming convention part), #6 - Procs & Organizing Code, and #7 - Comments and Whitespace.

2. I don't split code files across folders (the only exception being demos that come with libraries). Having to expand and collapse folders makes it harder to find things. If you have so many code files that you can't manage viewing them all at once, you should identify parts of your game that can be implemented as libraries your game uses.

3. I use common prefixes in filenames. All stuff related to mobs starts with "mob-", for example mob-stats.dm, mob-movement.dm, mob-skills.dm.

4. I don't tolerate messy code. I hardly ever write code the most organized way on the first try. But, because the code uses good naming conventions and has whitespace and comments, the code is easy to change. If I get something that works, but isn't ideal, I can easily change it. If you write messy code and get it to the point where it almost works, you're inclined to leave it alone for fear that any change might introduce bugs.
I'm about to go to bed, and thus have no time to check if I've read all of those articles, but I know for sure I have read most of those articles FA just linked to and I found them to be very well written. Definitely worth giving a read in my opinion, in fact I wish I had found them back when I was learning the basics and what not instead of much later.

As for folders, they can be useful, but for me I usually only use them for graphics. It's pretty easy to go through code files if all of your graphics are in another folder, or folders. It's also easy to go through graphics if you keep it simple and use good names or categories for each folder.
4. I don't tolerate messy code. I hardly ever write code the most organized way on the first try. But, because the code uses good naming conventions and has whitespace and comments, the code is easy to change. If I get something that works, but isn't ideal, I can easily change it. If you write messy code and get it to the point where it almost works, you're inclined to leave it alone for fear that any change might introduce bugs.

It's worth noting some BYONDers take this to the extreme and end up not getting anything done. I think more appropriate advice would be to rewrite things sometimes, but to avoid changing things that are already rooted deep in the code and would be hard to rewrite unless it is unavoidable (good coding conventions can help make code more easily changeable, however).
In response to Toadfish (#6)
Toadfish wrote:
It's worth noting some BYONDers take this to the extreme and end up not getting anything done. I think more appropriate advice would be to rewrite things sometimes, but to avoid changing things that are already rooted deep in the code and would be hard to rewrite unless it is unavoidable (good coding conventions can help make code more easily changeable, however).

That's true. There are a couple of ways this can be a problem:

1. People are afraid to write any code before they have, in their head, figured out what the best way is (and they keep changing their mind about which way is best).

2. People waste time redoing things that don't need redoing.

I think I've posted something along these lines somewhere but I can't find it. If you're going to rewrite something, make sure it's a significant improvement. Initially focus on changes to the API. You can change the inner workings later on without any worry but you want to figure out the API before you have a lot of things that are calling it. If you're making definite improvements to the code it's beneficial to the project and it's a good exercise for you. At first it may take you many rewrites to settle on the best way to do something but you'll only get better with practice.

This is something a lot of people avoid. People let their projects get messier and messier (sometimes they don't even realize it's happening) and it gets to the point where they can't continue working on the project and it's not feasible to clean everything up (because it's such a mess). Since these projects just get scrapped, their developers never get the practice at cleaning up code and their next project is bound to turn out the same way. You have to keep the code clean as you go.

Also, going back to tidy up existing code doesn't have to involve complete rewrites. Depending on how good of a job you did writing the code in the first place, it can be as simple as going back to make sure the code is properly commented.