RDNWiki: DOWScar/Primer/BestPractices ...

SCAR Primer: Best Practices

Coding Standards

A set of coding standards makes SCAR files easier to read, maintain and troubleshoot and organise. Using the same standard throughout a campaign (especially if working with a group of others) makes it easier to make sure everything works. Following coding standards like these used by Relic, and the Naming Conventions too, can help save time.

Indenting and Overall Structure

Having functions indendented correctly, using the if statements as new indents, makes it easy to seperate different if statements. We indent like this:

if true then
	-- Statement indented.
end

For readability, we should have only a single statement per line, such as new rule calls:

if true then
	-- add some objectives
	Objective_Add( OBJ_PRIMARY, true )	-- primary objective
	Objective_Add( OBJ_SECONARY, false )	-- secondary objective
end

You should indent levels appropriatly to thier depth – such as for multiple if statements, like follows:

function TestFunction
	if true then
		-- Statement indented
	end
end

A smart use of white space can help to break up large function calls or table creations (sometimes at the same time):

-- create the modifier
local modifier = Modifier_Create(
	MAT_SquadType,			-- This modifier will be applied to a squad blueprint
	"sight_radius_modifier",	-- Modify entity sight radius
	MUT_Multiplication,		-- Multiply sight radius by 2 non exclusive
	false, 
	2.0, 
	squad_list[i]			-- Do this to all squads of type...
)

Identifier and Function (Rule) Declarations

Identifiers, or variables, should usually be defined with a default variable at the top of the function they are used in, if local, or if global, in the initialisation call of a script. If the variable is only used in a small snippit of code, it is alright to just have it defined where it is used.

function TestFunction()
	local myvariable = true

	-- ...more code
end

Remember variables should follow the standard naming conventions.

The names of functions and rules should be lower case, with each word capitalized.

• Function_Name – Start function and function name words capitalized.
• Rule_RuleName – Start game rules functions with “Rule_"

Such as:

function Function_HowManyOrks( playerid )
function Function_KillCommander()
function Rule_ChaosObjectiveCheck()
function Rule_Ending()

Boolean Conditionals

In the case of Boolean variables, the important fact to test against true and false, never 1 and 0 in SCAR. If you try and mix these types, it will cause an error!

The conditionals (if statements) in SCAR are tested to be true or false. Obviously, we can test various things like this:

myvariable = true
if myvariable == true then
	-- This always fires
end
if myvariable == false then
	-- This never fires
end

Other ways of testing with boolean results:

myvariable = 10
-- First statement.
if (myvariable > 5) == true then
	-- This always fires
end
-- Second statement - This is exactly the same as the first one, and more acceptable for use.
if myvariable > 5 then
	-- This always fires too.
end

Naming Conventions

This information is from the ScarDoc with edits.

• Function_Name – Start function and function name words capitalized.
• Rule_RuleName – Start game rules functions with “Rule_"
• avariablename – Variable names are all lowercase.
• sg_sgroupname – Start SGroups with “sg_"
• eg_egroupname – Start EGroups with “eg_"
• mkr_markername – Start Marker Names with “mkr_"
• t_tablename – Start Tables with “t_"
• g_variablename – Start global variables with “g_" Create these at the top of the file and not in your functions.
• png_pingname – Start ping names with “png_"
• local variablename – The “local” tag means this variable can only be used in the current function
• Use true and false instead of 1 and 0

Links

LUA Wiki
SCAR
Wiki Home

End of Page