KSI-GS (Coding Standards)
 

The following are scripting rules designed for three purposes:

1) To improve the readability of your code.
2) To make your code easier to debug.
3) To minimise errors in your code.

Adhere to them, or Kaimetsu will punch you in the eye and never help you with your code.

DEFINITIONS

Conditional Statement

A piece of code that can be evaluated and declared either true or false. For example, 'playerrupees>20' is a conditional statement; it is true if the player has more than 20 rupees, and false otherwise. 'timeout' is also a conditional statement (along with all other events); it returns true if the flag is set and false if not.

Code Block

A code block is a section of code delimited by braces ('{' and '}'). They can be used to specify the behaviour of many structures, including if, while, for, function and with. Below are some examples.

NPC Code:

---

if(playerenters){

 greetplayer();

}



function greetplayer(){

 if(playerap>60){

  message Hello! So good to see you!;

 }

}

---

Event Block

An event block is a special type of code block. It specifies the behaviour of an if statement that responds to an event. For example, the blue text below is an event block:

NPC Code:

---

if(playertouchsme){

 stealdonuts();

 message Pardon me, sir, I seem to have accidentally jostled you;

}

---

Whereas this is not:

NPC Code:

---

if(this.donuts==30){

 message I am in heaven! ^_^;

}

---

Flags such as playerenters, playerchats and timeout are events. 'this.donuts==30' is just a condition.

Nesting

Nesting is the act of placing code blocks within other code blocks. In the following example, the green text is nested inside the blue.

NPC Code:

---

if(playerchats){

 if(strequals(#c,Where are my donuts?)){

  message I have no idea;

 }

}

---

The green text is part of the blue event block, but the blue event block is not part of the green text. Nesting is an integral part to all truly complicated scripts.

RULES

Rule One

Never include code that is not part of an event block. Think about when you want your code to execute, and place it in a corresponding event block.

Rule Two

Never nest event blocks within one another, or have a single event block depend on multiple events. It's not as bad to have a block react to one of multiple events (playerenters||timeout, for example), but it's still to be discouraged in most circumstances.

Rule Two A

Do not use multiple event blocks that respond to the same event. Check for an event once only.

Rule Three

Don't combine multiple commands on one line unless the relationship between them is clear and obvious. Each line should have only one purpose. The following example is fine.

NPC Code:

---

this.x=10; this.y=40;

---

This line of code simply sets a position - it's okay to put both commands on the same line because they both combine to achieve an obvious purpose. On the other hand...

NPC Code:

---

this.x=10; rupees=100;

---

This code is poor. There is no obvious link between setting an x coordinate and modifying a rupee count.

Be careful about what you consider obvious - as the programmer, you have an automatic insight into the code's purpose. Others will need to figure it out themselves.

Rule Four

Similarly to rule three, do not combine unrelated conditional statements. Instead of writing shambling messes like this:

NPC Code:

---

if(playerrupees>5&&this.monkey==84&&strequals(#g,C  OOLGUYS)){

 message WORD UP DAWG WOOT LOL;

}

---

Try to organise your statements by nesting them, like this:

NPC Code:

---

if(strequals(#g,COOLGUYS)){

 if(playerrupees>5){

  if(this.monkey==84){

   message Yay, our script is now phat;

  }

 }

}

---

Here we have an issue of readability vs efficiency. Intuitively, it makes more sense to check the guild first (if they're not in the guild, we don't give a damn how many monkeys they have). However, the order of evaluation will not change the operation of the script and it's usually more efficient to check normal variables than strings. Try to strike a balance between the two factors, and remember to comment the code if necessary.

Rule Five

Use '==' when comparing two values for equality.
Use '=' when assigning a value to a variable.

Rule Six

Beware deprecated commands. These are old parts of the scripting engine that are no longer supported because they have been replaced. Although they may still work, it is very bad form to use them. Examples:

playersays()
showimg @@@ (using showimg to draw text)
setlevel

Rule Seven

Name your variables appropriately. Variables that are prefixed with 'this.' are usually only necessary if the variable's value has to stay unchanged between executions of the script. If you're just storing a temporary variable, don't add the prefix. As well as small efficiency improvements, this will make your script more readable - it allows people to deduce more about a variable from its name.

Rule Eight

If your script is checking multiple possibilities and they are mutually exclusive (ie, they can't both be true), use elseif instead of a string of ifs. It's more efficient (Graal doesn't always need to evaluate all the conditions), and it adds implicit meaning to your code.

(More rules will come if/when I think of them)

;o
mk

Very good. ::Claps::

Re: KSI-GS (Coding Standards)
 

I noticed at the first part you said 'timeout' was a conditional statement. Then towards the end you called it an event. Whats up, dude?

Re: Re: KSI-GS (Coding Standards)
 

Event flags are conditional statements.

Re: Re: Re: KSI-GS (Coding Standards)
 

Hmm, I see.

Re: KSI-GS (Coding Standards)
 

I agree that things such as playersays() and setlevel, etc. need NOT be used, but I think showimg is still valid. To me, I find it easier to use than showtext purely because I've used showimg@@@ for so long. Sometimes when debugging, I'll start with it displaying like text rather than the image, and then change the string to the actual image and it's much easier to edit.
Anyways, I just think that showimg@@@ is the exception there and that it's still fine to use.
---Shifter

Clearly, this position is deprecated and the GST suggests that you do not use showimg @@@ or anything else that has been superceded by more useful devices. This includes old gscript. --- #gscript

Then you don't understand the concept of deprecation.

Define the concept of deprecation

Sorry, but I'm not going to waste my time indulging your ignorance. There's a big internet right at your fingertips, and it has all the answers you want.

I'm a little nicer than Mr. Kai, so I'll tell you what I think :) .

It is easier for the Graal.exe to break down everything between just the commas rather than break down the commas then have to break down the '@' signs. Takes less time and less proccesing power.

I'm not sure if that is correct, just a guess from my common sense vault.

That's not the definition of deprecation. Look it up.

That was why it is easier for Graal to use the new showtext rather than showimg for showing text. Anyone can look it up :\ .

not really true, the code for showtext is probably exactly the same, which is why, unless stefan fixed it, if you use @ as the text graal wont show

He must of fixed it :) .