Ways to keep your scripting organised

Ive always thought that my script looked messy, and i couldt figure out what the script is for, if i look back a month after.
So i thought that i would make this thread, were you guys can post tips and tricks to keep the scripts organised!
Inside the script, (Use // to make comments, and tell what the things do) and outside (Like put it in folders).

 

Use spaces to make it look neat. For instance, I divide my 'Player' script into different sections using empty li:

Player.js

Code (csharp):

1. var myHealth : int = 100;
2. var myMana : int = 200;
3.  
4. var myAmmo : int = 50;
5. var myGrenades : int = 3;
6.  
7. function Start() {
8.        Debug.log("Do stuff!");
9. }
10.  
11. function Update() {
12.     if (myHealth <= 0) {
13.         Suicide();
14.     }
15. }
16.  
17. function Suicide() {
18.     Debug.log("Bam! I am dead!");
19. }

Notice how I divide different variables into categories using spaces. I also divide different functions by spaces as well.
I also use 'Tab' to make some lines of script move forward to look highlighted.

If your project is large (developed for years) then I would advise you to add comments as you might forget how your own code works!

This is my way of organizing things. I wonder my if there are any other methods to make script look neat.

Hope this helps.

Cheers!

 

I'm totally new to Unity, but in Flash for big projects, I used to think a lot about how my different classes would work together. I think it's a bit similar in Unity where you have to make a clever use of prefabs.

Also you might want to assign a specific task to each objects you create and respect that principle by only use this object for what he was created for. For example, if you start using the MainCharacter script to handle stuffs like game over, display info, etc. it will quickly get messy because you will never know who do what.

 

Code (csharp):

1.  
2. #region myregionname
3.  
4. #endregion
5.  

Very useful for organization as long as your IDE can collapse it.

 

Add comments. Oftimes I start a function by naming it what it is.. "UnsheathSword ()" for example.. and then comment each line of code or set of subfunctions i will need to do so
//Check boolean isUnsheathed and If sword is already unsheathed then return
//If boolean isUnsheathed is false then run unsheathSword animation
//Set isUnsheathed boolean to true
...and then fill in the code for each step.
Call the script by exactly what is does "UnsheathSword.js" / "UnsheathSword.cs" and call the function from a control script you have cached the UnsheathSword component in with UnsheathSword.UnsheathSword()_

HTH

 

Triple slashes will let you add comments describing the method/property below which will be picked up in intellisense.

Code (csharp):

1.  
2.     /// <summary>
3.     /// Hit another player - reduces player health
4.     /// </summary>
5.     /// <param name="collider">The other player that was hit</param>
6.    void Hit(Collider collider) { }
7.  

 

Code (csharp):

1.  
2. /*
3. Brief description of function following this comment
4. Describe parameters if there are any
5. */
6.  
7. void someFunction()
8. {
9.     //plain english version of the if statement (if an object is close enough)
10.     if(Vector3.distance(object1.transform.position, object2.transform.position) < 3.0f)
11.     {
12.         //description of purpose of this function in this context
13.         somethingSpecific();
14.     }//distance check - if (keep track of large if statements when you have a lot of them)
15. }//someFunction
16.  

If I am working on a big enough project, I'll go to that extent in documenting a function. I describe the function's purpose, the parameters and then proceed in every significant line what the line is doing. On large if statements in code where you have a lot of large nested if statements, I'll add a comment after braces that indicate which if statement the brace is closing.

Some people go to the extent to actually have proper ///<summary> tag documentation, but that's more for group projects you may need to document for the person who eventually replaces you on the project.

 

I find the ///<summary> documenting to be useful even for myself thanks to Intellisense. So when I go to use my function from another class, I can see my summary of what each parameter is and what I'm supposed to pass in, and what the function does.

 

I prefer:

Code (csharp):

1. #region Region Name
2.  
3. #endregion Region Name

Even though MonoDevelop dosen't handle it well (what else is new?), the reason it's a good idea to include the region name on the endregion directive, is because regions can get long, and it's helpful to know what part of the code you're leaving. Nine times out of ten, I edit my code with everything expanded. I very seldom collapse all of my methods down to their signatures when coding.

 

Everything you ever need to now about proper coding practices is right here: https://www.thc.org/root/phun/unmaintain.html

 

This is great. What I normally do is try and break everything down into small classes. The biggest problem I run into is not remembering where things are when I come back to code a month or so later. I am forced to learn my own code again and it can be a big pain. By using small classes(>100 lines) you can quickly navigate your scripts from a top level. If you are say adding money to a players account you should have a class that can maintain money transactions by itself and not grouped in with other non money related issues. I always open other people code and see a huge player manager script that contains hundreds of line of code that deal with everything the player can do. Break everything down into small manageable scripts, it may be more work to setup in the beginning and you will have more scripts in the end but as far as maintaining it, you will love life.

 

LOL thats so funny cause i obsessively collapse everythign im not working on. Keeps me focused for some reason.

 

Lol, unfortunately this is me I admit it.

I have three or four main classes (I'm using Unityscript so actual separate scripts), that are getting very large in terms of lines of code. So not only do I have to endlessly scroll down to the function or line I'm looking for, but I also have to study my own code for a bit to figure out just where I'm at in relation to other things.

I do comment my code regularly now, so that helps, but you're right, I hate having to re-learn my own code. It's such a time waster But this is my first game, so I'm trying to learn.

 

Yeah I did for awhile until one day I just trained myself to say if I am writing more than 100 lines in a class, stop and figure out a way to break it apart. It does sometimes make it a little more complicated but if you smartly break them down you can contain everything in a nice little bubble. I have even started making a class just to hold global values then organize them by regions.

 

Scripting:
Use all mentioned - //<- comments, ///<- Summary and //<-End of complex IF / FOR LOOPS

Project:
Add "_Project Info" folder and include a plain text (e.g. Notes.txt) file to record project related information; esp with assets from store. Many do not include a version so unless you record it; WTH knows what version it is and if it should be updated. <-Note, Tasharen does great at this; all packages include the version info (thanks Aren!).

Test yourself: go look at some older code (if you have any), say from 6 months or 1 year or more ago and try and figure it out

Bottom line: IMO you can never really over comment your code.


Oh and for the love of PETE, DO NOT USE STRING VALUES all over your code!
Shameless blog referral <- sorry...