SRL Archive - OSR Beginner Scripting Tutorials

SRL/Simba Standards (with examples)


Shuttleu

2010-11-29 11:15:14

Standards are a set of rules that you should follow to ensure that the code you write is easily readable not only you but others as well. This is a must if you want to apply for SRL Members or even want help on your code, it allows people to read and understand what your doing, so if you need help, others can easily find the problem, if you apply for members, people can read what you do so they can decide if your ready. Overall it makes your code look a lot neater, nicer to look at and much easier to read.

This tutorial is for people who want to use proper standards in their scripts but want examples on how they should do them
I realised that there was not already a tutorial which done this, so i decided to write it

All information has come from the original standards post from Kaitnieks http://www.kaitnieks.com/scar/scriptingsta/

Indenting will be two spaces per level. You can indent by selecting text in Simba and pressing Tab and decrease the indent by pressing Shift+Tab.
{YES}
begin
Writeln('Hi');
Writeln('This is indented');
end;

{NO}
begin
Writeln('Hi');
Writeln('This is not indented');
end;
Margins will be set to 80 characters. Try not to make too long lines.
{YES}
i := SomeProcedure(x, y, f, r, t) + SomeProcedure(x, y, f, r, t) +
SomeProcedure(x, y, f, r, t) + SomeProcedure(x, y, f, r, t) +
SomeProcedure(x, y, f, r, t) + SomeProcedure(x, y, f, r, t);
{NO}
i := SomeProcedure(x, y, f, r, t) + SomeProcedure(x, y, f, r, t) + SomeProcedure(x, y, f, r, t) + SomeProcedure(x, y, f, r, t) + SomeProcedure(x, y, f, r, t) + SomeProcedure(x, y, f, r, t);

The begin statement appears on its own line. The end statement always matches the begin statement by columns.
{YES}
begin
begin
Writeln('Hi');
Writeln('This is indented');
end;
end;

{NO}
begin
begin
begin
Writeln('Hi');
Writeln('This is indented');
end;
end;
end;

Do not combine two or more statements on a single line. Write each on its own line.
{YES}
i := 1;
x := 3;

{NO}
i := 1; x := 3;

Use semicolons at the end of the lines except after var, begin, then, else, repeat, do and before else.
{YES}
var
i: Boolean;
x: Integer;

begin
if (i) then
Writeln('hi')
else
begin
repeat
i := True;
until(i);
end;
for (x := 0) to 3 do
Writeln(x);
end;

{NO}
var;
i: Boolean;
x: Integer;

begin;
if (i) then;
Writeln('hi');
else;
begin;
repeat;
i := True;
until(i);
end;
for (x := 0) to 3 do;
Writeln(x);
end;

Use spaces after commas and arithmetical signs.
{YES}
i := 2 + 3 + 5;

{NO}
i := 2+3+5;
There shall never be white space between an open parenthesis and the next character.
{YES}
Writeln('Correct');

{NO}
Writeln( 'Incorrect' );
Object Pascal language reserved words and key words shall always be completely lowercase. Never capitalize words that Simba displays in bold. It's completely unnecessary and looks ugly!
{YES}
var
s: string;
i: Integer;

begin
for (i := 0) to 3 do
Writeln(i);
if (i = 3) then
Writeln('i = 3');
repeat
Writeln(s);
until(s = '');
end;

{NO}
Var
s: String;
i: Integer;

Begin
For (i := 0) To 3 Do
Writeln(i);
If (i = 3) Then
Writeln('i = 3');
Repeat
Writeln(s);
Until(s = '');
End;
Routine names shall always begin with a capital letter and be PascalCase for readability.
{YES}
procedure FormatHardDrive;

{NO}
procedure formatharddrive;
Routines shall be given names meaningful to their content.
{YES}
procedure Proggy;

{NO}
DoStuffWithStuff
Where possible, procedure and function formal parameters of the same type shall be combined into one statement
{YES}
procedure Test(x, y, z, a, b, c: Integer; f, g: string);

{NO}
procedure Test(x: Integer; y: Integer; z: Integer; a: Integer; b: Integer; c: Integer; f: string; g: string);
All formal procedure and function parameter names will be meaningful to their purpose.
{YES}
procedure ScreenCoords(x1, y1, x2, y2: Integer);

{NO}
procedure ScreenCoords(a, b, c, d: Integer);
All functions should always return some value. Do not rely on Simba initializing procedure return value automatically!
{YES}
function ReturnNumber: integer;
begin
{do stuff}
Result := 123;
end;

{NO}
function ReturnNumber: integer;
begin
{do stuff}
end;
Variables will be given names meaningful to their purpose. That includes local and loop control variables, although in this case single character names are acceptable.
{YES}
var
BoneDTM, BankSymb, Flax: Integer;

{NO}
var
DTM1, DTM2, DTM3: Integer;
Boolean variable names must be descriptive enough so that their meanings of True and False values will be clear.
{YES}
var
FoundColor: Boolean;

{NO}
var
a: Boolean;
Variable declarations start in next line after var statement and are indented.
{YES}
var
x, y, z: Integer;

{NO}
var x, y, z:Integer
Use of global variables is discouraged. However, they may be used when necessary.

Not really a example for this one, but whenever you can use local variables, use them instead of global variables.

DTMs will be marked with dtm prefix.
{YES}
var
dtmFishingSpot, BoneDtm: Integer;

{NO}
var
FishingSpot, Bone: Integer;
Bitmaps will be marked with bmp prefix.
{YES}
var
bmpFishingSpot, BoneBmp: Integer;

{NO}
var
FishingSpot, Bone: Integer;
Type names that are reserved words shall be completely lowercase. For other variable names, the first letter shall be uppercase, and the rest shall be camel-capped for clarity.
{YES}
var
i: Integer;
s: string;

{NO}
var
i: integer;
s: String;
The most likely case to execute in an if/then/else statement shall be placed in the then clause, with less likely cases residing in theelse clause(s). This improves performance as well as readability.
{YES}
var
b: Boolean;

begin
b := True;
if (b) then
Writeln('b is true')
else
Writeln('b is false');
end;

{NO}
var
b: Boolean;

begin
if (b) then
Writeln('b is true')
else
Writeln('b is false');
end;
If multiple conditions are being tested in an if statement, conditions should be arrange from left to right in order of least to most computation intensive. If condition statement is complex, replace it with function or Boolean variable with a meaningful name. This improves readibility and makes code self-documenting.
{YES}
var
Bool1, Bool2: Boolean;

begin
Bool1 := True;
Bool2 := False;
if (Bool1 or Bool2) then
Writeln('hi');
end;

{OR}
var
Bool1, Bool2: Boolean;

function OneIsTrue: Boolean;
begin
Result := Bool1 or Bool2;
end;

begin
Bool1 := True;
Bool2 := False;
if (OneIsTrue) then
Writeln('hi');
end;

{OR}
var
Bool1, Bool2, Resultant: Boolean;

begin
Bool1 := True;
Bool2 := False;
Resultant := Bool1 or Bool2;
if (Resultant) then
Writeln('hi');
end;

{NO}
var
Bool1, Bool2: Boolean;

begin
Bool1 := True;
Bool2 := False;
if (Bool2 or Bool1) then
Writeln('hi');
end;

enjoy

~shut

Cstrike

2010-11-29 11:21:07

Great job :)

Random question:
For loops you have
i:=0 (no spaces)
For inputting data to variables you have:
bool1:= True; (1 space)

Minor minor point indeed, but do you think both should be the same? Different?
I personally do what you do with for loops (i:=0), though I've always done declaration like:
x := 5;

Shuttleu

2010-11-29 11:27:35

From: cstrike
Great job :)

Random question:
For loops you have
i:=0 (no spaces)
For inputting data to variables you have:
bool1:= True; (1 space)

Minor minor point indeed, but do you think both should be the same? Different?
I personally do what you do with for loops (i:=0), though I've always done declaration like:
x := 5;


good point
i suppose my standards is generaly good, but when it comes to loops they are sloppy

it should be
x:= 5;
and
for (x:= 0) to 5 do

ima update first post

~shut

Harry

2010-11-29 11:32:25

It should be "x := 5;", I think. Why space the second part but not the first?

Shuttleu

2010-11-29 11:35:19

From: Harry
It should be "x := 5;", I think. Why space the second part but not the first?


Actually, I think your right, I assumed the first didn't have a space because that's how I have always done it and there was nothing on the original standard deceleration.

~shut

Tickyy

2010-11-29 16:29:02

From: Shuttleu

Object Pascal language reserved words and key words shall always be completely lowercase. Never capitalize words that SCAR displays in bold. It's completely unnecessary and looks ugly!
Yes

var
s: string;
i: Integer;

begin
for (i := 0) to 3 do
Writeln(i);
if (i = 3) then
Writeln('i = 3');
repeat
Writeln(s);
until(s = '');
end;
No

Var
s: String;
i: Integer;

Begin
For (i := 0) To 3 Do
Writeln(i);
If (i = 3) Then
Writeln('i = 3');
Repeat
Writeln(s);
Until(s = '');
End;



Boooo :thumbsdown:


From: Shuttleu

The most likely case to execute in an if/then/else statement shall be placed in the then clause, with less likely cases residing in theelse clause(s). This improves performance as well as readability.
Yes
var
b: Boolean;

begin
b := True;
if b then
Writeln('b is true')
else
Writeln('b is false');
end;
No
var
b: Boolean;

begin
b := True;
if b then
Writeln('b is false')
else
Writeln('b is true');
end;


i don't see a difference here… ?



The rest was great :D!

Shuttleu

2010-11-29 16:46:47

From: Tickyy
Boooo :thumbsdown:




i don't see a difference here… ?



The rest was great :D!


thanks for pointing that out, fixed :D

~shut

noidea

2010-11-29 17:34:51

When tabing in Simba, it automatically indents two spaces. Much better for people that have coded in different languages.

Gu3st...

2010-11-29 18:02:05

From: Shuttleu
Yes
begin
Writeln('Hi');
Writeln('This is indented');
end;
No
begin
Writeln('Hi');
Writeln('This is not indented');
end;


Both of those are intended

i luffs yeww

2010-11-29 18:40:12

[php]
var
i: Boolean;
x: Integer;

begin
if(i)then
Writeln('hi')
else
repeat
i := True;
until(i);
for x := 0 to 3 do
Writeln(x);
end;
[/php]

[php]
var
s: string;
i: Integer;

begin
for i := 0 to 3 do
Writeln(i);
if(i = 3)then
Writeln('i = 3');
repeat
Writeln(s);
until(s = '');
end;
[/php]

All functions should always return some value. Do not rely on Simba initializing procedure return value automatically!


Functions will give an error if there is no Result := Something;.

[php]
var
x, y, x: Integer;
[/php]

DTMs will be marked with dtm prefix.


A suffix will suffice as well.

Bitmaps will be marked with bmp prefix.


A suffix will suffice as well.

[php]
function TheyAreEqual: Boolean;
begin
Result := Bool1 or Bool2;
end;
[/php]

Your name for the function is contradicting to what it returns.

KingKong

2010-11-29 19:54:52

From: Zyt3x
Both of those are intended


I see a few people use intended as well. But I thought it was indented, not intended. Correct me if i'm wrong.

Shuttleu

2010-11-30 03:15:38

From: i luffs yeww
[php]
var
i: Boolean;
x: Integer;

begin
if(i)then
Writeln('hi')
else
repeat
i := True;
until(i);
for x := 0 to 3 do
Writeln(x);
end;
[/php]

[php]
var
s: string;
i: Integer;

begin
for i := 0 to 3 do
Writeln(i);
if(i = 3)then
Writeln('i = 3');
repeat
Writeln(s);
until(s = '');
end;
[/php]

what is wrong with these?
From: i luffs yeww

Functions will give an error if there is no Result := Something;.

it wont give a error, it will give a hint and still run

~shut

EvilChicken!

2010-11-30 03:33:59

I find everything in this tutorial to my liking.

If you also can combine the yes/no's in single code boxes, I'll rep+ you-.
Really, it just gets too much the way it currently is.

i luffs yeww

2010-11-30 05:08:16

What I posted was a corrected version of what you had. if..then statements are supposed to be if(Whatever)then.

Shuttleu

2010-11-30 18:51:52

From: EvilChicken!
I find everything in this tutorial to my liking.

If you also can combine the yes/no's in single code boxes, I'll rep+ you-.
Really, it just gets too much the way it currently is.

hmmm… how do you propose i combine them?
any ideas
or i could do it like this
{YES}
var
x: Integer;

{NO}
VAR
x: integer;
From: i luffs yeww
What I posted was a corrected version of what you had. if..then statements are supposed to be if(Whatever)then.


i suppose, but i think its better to only have brackets if there is going to be spaces such as "3 = 3" or "not RandomBoolean"
but if there is going to be one world like "RandomBoolean" or "TehBool" then it shouldnt have brackets
it seems neater that way

anyone else agree with me or i luffs yeww?

~shut

Sir R. M8gic1an

2010-11-30 19:52:10

I quite like this.

There'll be a forever argument on standardization, but I think this is a good place to keep the end result of it :)

~RM

i luffs yeww

2010-11-30 20:05:32

I got that from Kait's site ages ago. :p I don't care, just saying. I'm sure that site is still archived somewhere.

Sir R. M8gic1an

2010-11-30 20:08:36

From: i luffs yeww
I got that from Kait's site ages ago. :p I don't care, just saying. I'm sure that site is still archived somewhere.


Still is, but not written in this form and not on our forums ;)

~RM

i luffs yeww

2010-11-30 20:14:18

RM, do you have a link to it? :3

Sir R. M8gic1an

2010-11-30 20:18:10

From: i luffs yeww
RM, do you have a link to it? :3


:google:

i luffs yeww

2010-11-30 20:29:00

http://www.kaitnieks.com/scar/scriptingsta/

"if(Condition)then"

…

"if(I = 42)or(J = 42)then"

Oh. :p Looks like you got your whole guide from that anyway (almost), so yeah, you should see that it's in there.

Shuttleu

2010-12-01 03:14:45

From: i luffs yeww
http://www.kaitnieks.com/scar/scriptingsta/

"if(Condition)then"

…

"if(I = 42)or(J = 42)then"

Oh. :p Looks like you got your whole guide from that anyway (almost), so yeah, you should see that it's in there.


ok, i didnt notice it, fix'd

~shut

Nava2

2010-12-01 14:31:25

From: Nava2
I think a new list needs to be created, I'll start with the old ones, editted:

  • Indenting will be two spaces per level. You can indent by selecting text in SCAR and pressing Ctrl+Tab and move backwards by hitting Ctrl+Shift+Tab.
  • Margins will be set to 80 characters. Try not to make too long lines. This is because of general codings standards set by the Unix Terminal.
  • The begin statement appears on its own line. The end statement always
  • matches the begin statement by columns. Example:
  • Do not combine two or more statements on a single line. Write each on its own line.
  • Use semicolons at the end of the lines where appropriate. SCAR allows lines without semicolons but you should use them everywhere, except after var, begin, then, else repeat, do and before else.
  • Use spaces after commas and arithmetical signs.
  • Example:
  • There shall never be white space between an open parenthesis and the next character. As well, there will be a space between logical operators and conditions in conditional statements.
  • Example:
    if ((x = 5) and (y = 5)) then
    DoThis;
  • Object Pascal language reserved words and key words shall always be completely lowercase. Never capitalize words that SCAR displays in bold. It's completely unnecessary and looks ugly!
  • Routine names shall always begin with a capital letter and be camel-capped for readability.
  • Example:
  • Routines shall be given names meaningful to their content. Routine name DoStuffWithSyAndSy is not meaningful, but name OutputProgressReport is.
  • Where possible, procedure and function formal parameters of the same type shall be combined into one statement
  • Example:
  • All formal procedure and function parameter names will be meaningful to their purpose.
  • All functions should always return some value. Do not rely on SCAR initializing procedure return value automatically! This means: If its a boolean result, set it to false initially, if its an integer set it to 0/-1, and a string would be ''.
  • Variables will be given names meaningful to their purpose. These names will start with a lowercase letter and be Camel Capped for readability. That includes local and loop control variables, although in this case single character names are acceptable. For loop control variables, try to use the variables: i, j, k, l, and h.
  • Boolean variable names must be descriptive enough so that their meanings of True and False values will be clear.
  • Variable declarations start in next line after var statement and are indented.
  • Example:
  • Use of global variables is discouraged. However, they may be used when necessary. Global variable naming rules are as follow:
  • Forms and controls are prefixed with their individual prefixes. Examples: frmMainForm, lblUser, txtPassword, imgPreview etc. DTMs will be marked with dtm prefix as in dtmFishingSpot. Character sets will be marked with chr prefix as in chrChatChars. Bitmaps will be marked with bmp prefix as in bmpFishingNet. Include global variables will be marked with g prefix then include initials as in gOsiStartTime. Normal global variables will be marked with g prefix as in gNumFishCaught.
  • Type names that are reserved words shall be completely lowercase as in string. For other variable names, the first letter shall be uppercase, and the rest shall be camel-capped for clarity as in Integer.
  • The most likely case to execute in an if/then/else statement shall be placed in the then clause, with less likely cases residing in the else clause(s). This improves performance as well as readability.
  • For all condition statements, conditions will be encased in a set of parenthesis. This is general coding standard and allows for more obvious reading.
  • If multiple conditions are being tested in an if statement, conditions should be arrange from left to right in order of least to most computation intensive. If condition statement is complex, replace it with function or Boolean variable with a meaningful name. This improves readability and makes code self-documenting.
  • Use of informational file header is encouraged for all script and include files.
  • Use Script > Script Properties from SCAR menu to enter script information.
  • All variables, functions, procedures, and constants should be properly commented. One can choose their own style, but use of {} should be put forward over //.
  • Constants Constants should be used as often as possible. This allows for easier readability and self-explanatory code. Constants should be prefixed with a descriptive meaning, usually associated with the File or the Function. They will follow the format: *FILE*_*FUNCTION*_*VALUE*. They will be camel capped, and the *FILE* token can be left out if it is part of a script and only if it a local constant. If the Constant is used globally in a script it will be prefixed with "gbl".

Comments, ideas?


My revised copy of the kaitniek's standards.

Better from the general opinion of the uppers :p

Sandstorm

2010-12-01 14:37:07

Object Pascal language reserved words and key words shall always be completely lowercase. Never capitalize words that Simba displays in bold. It's completely unnecessary and looks ugly!

BOO!

Looks good :D. Except for that. Habit Begin/End ftl(w?).

EvilChicken!

2010-12-01 14:37:59

From: Shuttleu

or i could do it like this


That's a good solution.

And, I don't know which of you want what, but I think that parentheses should be wrapped around any if-statement. (that is; "if (Bool) then..".)

Boreas

2010-12-01 14:50:36

How about adding a sentence on what are standards? 'Standards are a set of standardized guidelines for formatting your code, so that you and others will be able to read it more clearly.' or something like that. Maybe also mention that in other languages spacing and indenting affects the code.

lordsaturn

2010-12-01 21:45:20

IMO indentation is the only thing that matters. Everything else is personal preference.

sf411

2011-09-13 09:08:19

for const and var, would something like this be acceptable?

const
nameOfSomething = 30;

BraK

2011-09-13 09:27:59

This is the correct way to do that statement.


const
NameOfSomething = 30;

sf411

2011-09-13 09:40:09

From: BraK
This is the correct way to do that statement.


const
NameOfSomething = 30;


OK then, I will do it that way. I am just use to using Visual Studio (C++,C#,etc), but this will not be a hard switch to do.

Lima Bean

2011-10-15 03:38:10

program loopy;

var
i: Integer;
s: string;

begin
for i := 0 to 3 do
if i = 3 then
Writeln('i = 3')
else
Writeln(i);
repeat
Writeln(s);
until(s = '');
end.

meh… lol

bevardis

2011-10-15 06:23:49

I learned much from this a few months a ago, thank you; )

Smoeltje

2013-01-08 03:19:22

Thanks, helped me alot :).

ahfederation

2013-03-25 11:08:50

Random question can't find solution of this :
const
x, aInteger, run, invCounter, runIsOn, thaTime, TreeColor3, y, z, logs, level, knife, TreeColor, TreeColors: integer;
Please help thanks

samerdl

2013-04-30 08:51:53

These are the official standards, correct? not just personal preferences, from other topics i saw that SRL looks for people that are more capable of scripting - than polishing.

Regardless i think both are very important.

Shuttleu

2013-04-30 08:55:44

Official as in set out by kaitnieks (the creator of scar) in 2004, yes.

Scriptability is much more important and standards, but people are going to have trouble reading your script if there are no standards as it will be hard to see where one bit ends and another starts

Plus having a universal look and feel is easier to learn

for example, most iOS apps share the design from the OS its self, because its a universal design and fits and looks well with everything, if there was no standards for design everything would look completely different.

~shut

wthomas

2013-05-03 22:50:19

This is useful, however where you talk about procedures/functions you mention that they start capitalized and then are camelCased; is this not the suitably named PascalCase?

Shuttleu

2013-05-04 17:36:42

From: wthomas
This is useful, however where you talk about procedures/functions you mention that they start capitalized and then are camelCased; is this not the suitably named PascalCase?


Yes, you are right
2.5 years and your the first to spot it

~shut

Zeta Matt

2013-09-17 19:35:13

Nice tut :) Updated scripts now, I only kept with my universal vars >.<

scrip writer1

2013-10-29 21:16:20

Thanks ill try to use this info