Windows When should I use a semicolon, and when should I not?

[lukeman3000]

I'm just a little confused as to what the rule is for semicolon usage at the end of lines. For example, in the tutorial video (for space rocks), there is a semicolon at the end of line 51. However, if I have one there, I'll get a syntax error when I try to build. So, going forward, what is the rule of thumb for when a semicolon should or should not be added at the end of a line?

 

[RefresherTowel]

The reason there's a syntax error there is because the semi-colon is WITHIN the brackets of the draw_text function. They've "extended" the function for readability purposes, the actual function would look like this if it weren't spread across multiple lines:

draw_text(room_width/2,250,"FINAL SCORE: "+string(global.gscore));

Adding in the semi-colon that you are talking about would be this:

draw_text(room_width/2,250,"FINAL SCORE: "+string(global.gscore););

That second example should be pretty clearly wrong (and it's a sloppy mistake to make in the tutorial). I don't know the exact terminology, but pretty much anywhere where there isn't a curly bracket or a colon ending a line, there should be a semi-colon:

if (something == something_else) { // No semi-colon here because of the curly bracket or colon
   a = b; // Semi-colon here because the line doesn't end in a curly bracket or colon
   var _inst = instance_place(x,y,object); // As above
   var _text = ""; // As above
   switch (c) { // None here because of curly bracket
      case 1: // None here because of the colon
         text = "Yes"; // One here because no curly bracket or colon
      break; // As above
   } // No semi-colon because of the curly bracket
} // As above

 

[Roldy]

In general the semi-colon is at the end of a statement, not a line.

// Here the semi-colon as at the end of the statement and line
some_function_call(argument0, argument1);

// Below is the EXACT same statement
some_function_call(
    argument0,
    argument1
    )
    ;

// The new lines don't actually matter.
// The compiler technically doesn't even see them.
// However the semi-colon (like a period in a sentence)
// denotes that the statement is complete

Typically additional white space doesn't matter, but punctuation and operators do.

// This statement
var a = 1;

// Is the same as this statement
var
a             =                1
;

// And these three statements
var a = 1;
var b = 2;
var c = 3;

// Are the same as these three statement
var a=1;var b=2;var c=3;

The semi-colons separate the statements, not the new lines or spaces.

There are some situations where the semi-colon can appear not at the end of a typical statment.

// Like a for loop with semicolons between the paranthesis
for( var _i = 0; i < 10; i++) {
  // do some stuff
}

// The above semicolons are still kinda marking the end of statements
// it just happens that the syntax of a for loop requires the statements
// to go inside the parenthesis of the for loop
// But in general the semi-colon go at the end of complete statements

 

[lukeman3000]

Ah, got it. Thanks guy. In watching the tutorial, in the next couple seconds I noticed that they corrected that error on the video - I just hadn't got there yet lol.

On another subject, what are best practices for spaces within functions and whatnot? For example, do you write

irandom_range(room_width*0.7,room_width)

or

irandom_range(room_width * 0.7, room_width)

It sounds like it doesn't matter; I'm just curious what most people do. To me, the second seems a bit easier to read.

 

[TheouAegis]

That is purely personal preference. As was said, white space does not matter between elements.

 

[Roldy]

Ah, got it. Thanks guy. In watching the tutorial, in the next couple seconds I noticed that they corrected that error on the video - I just hadn't got there yet lol.

On another subject, what are best practices for spaces within functions and whatnot? For example, do you write

irandom_range(room_width*0.7,room_width)

or

irandom_range(room_width * 0.7, room_width)

It sounds like it doesn't matter; I'm just curious what most people do. To me, the second seems a bit easier to read.

As said its preference, but also consistency. There are lots of styles for coding, but readability and consistency should be the goal.

Personally I go with what looks most like English: spaces after commas, punctuation and spaces before and after operators (your second example).

But you should always be prepared to adapt your style when working in another person's code or working at a company that has a set style. Consistency is more important for readability.

Having a style and being consistent is more important than the style itself.

Here is a big list of indentation styles alone:

Indentation style - Wikipedia

en.wikipedia.org

 

[Evanski]

I usually just put them at the end of statements

i = 0; Fish = apples*98; script_execute(66);

 

[kburkhart84]

You worried about where to put spaces in lines of code?!......just wait until you find people fighting/debating over what style to use for brackets' positioning.

I generally try to never split a single statement up into multiple lines....but depending on if I'm nested a few brackets layers in, and how long the line is, I will split something up. I split up generally if the line would go too long and be off the screen(I never want to scroll right in code). I hadn't had it happen in quite a while, but just yesterday I did some. This is from a 2.3 beta project(so uses the new structs), but I'm several bracket levels in here so you can see why I split a couple of statements up. My trick to keeping things readable when split up is usually by putting the "operator" type stuff at the end, and making sure to split the same way in the same area. note that the two lines there are split at the same exact point.

#region //__fhInputSetConflicts
function __fhInputSetConflicts()
{
    var numPlayers = __fhInputObjController.myConfiguration.numPlayers;
    var numActions = __fhInputObjController.myConfiguration.numActions;
    
    for(var currPlayer = 0; currPlayer < numPlayers; currPlayer++)//for each player
    {
        for(var currAction = 0; currAction < numActions; currAction++)//for each action
        {
            __fhInputObjController.myPlayers[currPlayer].myActionConfig[currAction].hasConflict = false;//assume there is no conflict
            for(var checkPlayer = 0; checkPlayer < numPlayers; checkPlayer++)//for each player
            {
                for(var checkAction = 0; checkAction < numActions; checkAction++)//for each action
                {
                    var samePlayer = currPlayer==checkPlayer;//are we checking the same player
                    var sameAction = currAction==checkAction;//are we checking the same action
                    if(!samePlayer || !sameAction)//if not checking the same player and action(checking against itself basically)
                    {
                        if(__fhInputObjController.myPlayers.myActionConfig[currAction].device ==
                            __fhInputObjController.myPlayers.myActionConfig[checkAction].device)//if the device is the same
                        {
                            if(__fhInputObjController.myPlayers.myActionConfig[currAction].input ==
                                __fhInputObjController.myPlayers.myActionConfig[checkAction].input)//if the input is the same as well
                            {
                                __fhInputObjController.myPlayers.myActionConfig[currAction].hasConflict = true;
                            }
                        }        
                    }
                }
            }
        }
        if(__fhInputObjController.myPlayers[currPlayer].myActionConfig[currAction].device == 0)//if an action is not set
        {
            __fhInputObjController.myPlayers[currPlayer].myActionConfig[currAction].hasConflict = false;//set conflict flag to false
        }
    }
}
#endregion