• Hey Guest! Ever feel like entering a Game Jam, but the time limit is always too much pressure? We get it... You lead a hectic life and dedicating 3 whole days to make a game just doesn't work for you! So, why not enter the GMC SLOW JAM? Take your time! Kick back and make your game over 4 months! Interested? Then just click here!

GML How do you keep your code clean and tidy?

Looking for tips on how to keep code clean, legible, and tidy. Particularly with nested If statements. I try my best to remember basic coding etiquette and I understand how everything works as I see it. Currently, I am the only one who needs to understand it as well so I'm not worried about if others can understand it as I do. I just find everything to be so cluttered when things get really in depth. I've made loops and switches to clean up some things that could help simplify things at a glance but I feel they can get just as convoluted as the trillion IF statements they handle.

I'm attaching an example of my style of coding if you care to look or if you'd like to attach some of your own I'd be happy to see them along with your reply. I'm not really looking for critiques on the logistics of how my code works since for my purposes it works for what I need it to do. More so just looking for ideas of how to be more visually structured and organized. I would love to hear from you and get any examples you may have to show.

Code:
//Adding Inventory
for(i = 0; i<MaxSlots; i++)
{   
    if(AddInv = true)//if obj_Player passes action to add inv (stores ItemID which is crop's image index +1)
    {
        switch(InvSlot[i])//cycle through InvSlots and check values
        {
            case ItemID: ItemStack[ItemID-1] ++;AddInv = false; break;    //If Item already exists in any inventory slot simply add to the stack count
            case 0:                                                        //If current slot has no value
                switch(ItemStack[ItemID-1])                                //Check stacks of the ItemID
                {
                    case 0: InvSlot[i] = ItemID; ItemStack[ItemID-1] ++; AddInv = false; break    //If Item has no stack value add Item to slot and add to stack count
                    case !0: InvSlot[i] = 0; ItemStack[ItemID-1] ++; AddInv = false; break        //If Item does have stack value add nothing to the slot and add to stack count
                }
            ;break
            
        }       
        if(InvSlot[(MaxSlots-1)] != 0)//prevents adding items when current maxslots are full
        {
            AddInv = false;   
        }   
    }//end of if AddInv = true       
}//end of Adding Inventory for loop
 

Sk8dududu

Member
I put my curly brackets on the same indentation line as the code so that it's easier to see what everything is referencing.
And I leave comments above the lines of code. If you leave it after its kinda messy.
Also leaving too many comments can be unnecessary and create clutter. Just use it for important things that are not obvious.
 

NightFrost

Member
I put comments on their own lines, unless I happen to comment some list like an enumerator. I tend not to commend closing braces unless there's lots of nesting and long stretches of code. A typical example of my code and commenting habits would be
Code:
// Enumerator for stuff components.
enum Stuff {
    Item1,    // Item1 explanation.
    Item2,    // Item2 explanation.
    Item3     // Item3 explanation.
}

// Loop to do some stuff.
for(var i = 0; i < Some_Length; i++){
    // Calculcate foo.
    var Foo = scr_calculate_foo(i);
    // If foo equals bar.
    if(Foo == Bar){
        global.Baz += Foo + Bar;
    }
    // Otherwise foo does not equal bar.
    else {
        global.Baz += Foo - Bar;
    }
}
 
Top