C4Script Style Guidelines: Difference between revisions

Maikel (talk | contribs)
No edit summary
Maikel (talk | contribs)
No edit summary
 
(16 intermediate revisions by 5 users not shown)
Line 1: Line 1:
== Scripting policy ==
Since many people are involved in the project, it is necessary to define some styling guidelines so that other developers can read your code more easily. Objects that have a public interface should be documented in a Javadoc-like syntax. Please adhere to this example if you edit or add new scripts.


Style guideline for coding C4Script in OpenClonk.
=== Example ===
The development is based on exchange of scripts. Therefore it is necessary to define some styling rules, so that other developers can read your code more easily.


=== Indentation ===
/**
 
''Object title''
Indent your code with tabs (ASCII 9). Use space (ASCII 32) for all other formatting.
''Description, including implementation details that might be interesting for other scripters''
 
  public func foo()
@author ''Author(s)''
*/
local some_variable;
/** ''Explanation of what the function does''
@param foo ''What the parameter foo is''
@return ''What comes out of this function''
*/
  public func DoSomething(int foo)
  {
  {
  bar();
  // ''implementation commentars''
  if (1)
  if (foo == DIR_Left)
  {
  {
  bar2();
  some_variable++;
CreateObject(Goal_Melee);
  }
  }
if (foo && some_variable)
foo = foo + 1;
return foo;
  }
  }


=== Braces ===
=== In words ===


According to the [http://forum.openclonk.org/topic_show.pl?tid=208 poll] in the forum:
====Naming conventions====
 
* generally, use meaningful identifiers which are self explanatory: e.g. <tt>weapon_strength</tt> rather than <tt>iStr</tt>
Braces are on their own line, on the same level of indentation as the structure they belong to. You may add braces around single statements in if statements if the first block or an else block has them.
* for variables don't use hungarian notation, preferably use <tt>lowercase_separated_by_underscores</tt>
 
* for functions use <tt>CamelCase()</tt>
if (bar)
* for static constants use <tt>PREFIX_Identifier</tt>
{
* Prepend new style effects with <tt>Fx</tt> like <tt>FxNewStyleEffect</tt>
foo();
}
else
{
foo2();
}
 
=== Spaces ===
 
Keywords followed by a space: <tt>if, while, for</tt>
 
Commas are followed by a space, function names not. <tt>-></tt>, <tt>->~</tt>, <tt>++</tt> and <tt>--</tt> don't need spaces, other operators do. <tt>+</tt> and <tt>-</tt> don't need spaces either when used as algebraic signs, otherwise they do.
 
var foo = 0;
foo++;
if (foo && bar)
{
foo = foo + 1;
}
 
=== Control Structures ===
 
Control structures with a single statements are written without braces. You may add braces for readability.
 
Statements are written in a new line.
 
=== Comments ===
 
'''Please comment your script where it's necessary.'''
 
You may format your comments as you wish:
// single line comment
// multiline
// comment
/* multiline
    comment 2 */
// Unnecessary comment:
// Increase i by one
i++;
// Necessary comment:
// This starts the whole effect, casts particles and stuff
CreateObject(BAR1, 0,0, GetOwner())->foo();


Especially for German scripters: '''comment in English please!'''
====Indents, braces and spaces====
* indent code with one tab
* use the braces on own lines on the same indent level as the control structure / function declaration
* <code>{...}</code> braces are not required for single line statements but can be added if it improves readability
* use spaces between operators like +, -, *, /, &&, || etc.
* keywords (<tt>if</tt>, <tt>while</tt>, <tt>for</tt>, etc.) are followed by a space.
* function names are not followed by space, commas are


== IDs ==
====Access specifiers for object methods====
Non-global methods that are part of a public interface and intended to be called from other objects or scripts, should be prefixed with the <tt>public</tt> keyword. As a part of the public interface of an object <tt>public</tt> methods should be documented with comments accordingly.
Non-interface methods should be prefixed with the <tt>private</tt> keyword. Do not leave out the access specifier. The keyword <tt>protected</tt> is deprecated.


The difference with CR is that OC allowes for IDs to have more than four characters. The main OC content will use the namespace Core_, so use this as prefix for all your objects which go into the main object pack for OC.
====Comments and Documentation====
* especially for library objects or objects with an interface used by other objects, write an introductory comment including title, author(s) and a description
* please comment your script where it is necessary for other scripters to understand what you've done
* please use Javadoc-like syntax when documenting your code so that a reference can be automatically created from it later


=== Objects.c4d/Libraries.c4d ===
====Naming prefixes for IDs====
* for libraries, icons and GUI elements: <tt>Library_*</tt>, <tt>Icon_*</tt>, <tt>GUI_*</tt>
* for goals, rules and environment objects: <tt>Goal_*</tt>, <tt>Rule_*</tt>, <tt>Environment_*</tt>
* for spells: <tt>Magic_*</tt>
* objects which are exclusively used by their parent objects should prefix their parent object name. e.g. <tt>ParkourCheckpoint</tt> for a checkpoint of the parkour goal


ID's can now have more than four characters, so in the future use: Core_Library_.
====Misc====
* For C4Script veterans: You don't need to write <code>#strict 2</code> at the start of each script. All scripts are considered to be in ''strict 2'' style
* If you need multiple statements in a block, use one (<tt>if (...) { foo(); bar(); }</tt>)! Avoid constructs like <tt>if (...) foo() && bar();</tt> or <tt>if (...) Or(foo(), bar());</tt>

Latest revision as of 18:25, 4 February 2017

Since many people are involved in the project, it is necessary to define some styling guidelines so that other developers can read your code more easily. Objects that have a public interface should be documented in a Javadoc-like syntax. Please adhere to this example if you edit or add new scripts.

Example

/**
	Object title
	Description, including implementation details that might be interesting for other scripters

	@author Author(s)
*/

local some_variable;

/** Explanation of what the function does
	@param foo What the parameter foo is
	@return What comes out of this function
*/
public func DoSomething(int foo)
{
	// implementation commentars
	if (foo == DIR_Left)
	{
		some_variable++;
		CreateObject(Goal_Melee);
	}

	if (foo && some_variable)
		foo = foo + 1;

	return foo;
}

In words

Naming conventions

  • generally, use meaningful identifiers which are self explanatory: e.g. weapon_strength rather than iStr
  • for variables don't use hungarian notation, preferably use lowercase_separated_by_underscores
  • for functions use CamelCase()
  • for static constants use PREFIX_Identifier
  • Prepend new style effects with Fx like FxNewStyleEffect

Indents, braces and spaces

  • indent code with one tab
  • use the braces on own lines on the same indent level as the control structure / function declaration
  • {...} braces are not required for single line statements but can be added if it improves readability
  • use spaces between operators like +, -, *, /, &&, || etc.
  • keywords (if, while, for, etc.) are followed by a space.
  • function names are not followed by space, commas are

Access specifiers for object methods

Non-global methods that are part of a public interface and intended to be called from other objects or scripts, should be prefixed with the public keyword. As a part of the public interface of an object public methods should be documented with comments accordingly. Non-interface methods should be prefixed with the private keyword. Do not leave out the access specifier. The keyword protected is deprecated.

Comments and Documentation

  • especially for library objects or objects with an interface used by other objects, write an introductory comment including title, author(s) and a description
  • please comment your script where it is necessary for other scripters to understand what you've done
  • please use Javadoc-like syntax when documenting your code so that a reference can be automatically created from it later

Naming prefixes for IDs

  • for libraries, icons and GUI elements: Library_*, Icon_*, GUI_*
  • for goals, rules and environment objects: Goal_*, Rule_*, Environment_*
  • for spells: Magic_*
  • objects which are exclusively used by their parent objects should prefix their parent object name. e.g. ParkourCheckpoint for a checkpoint of the parkour goal

Misc

  • For C4Script veterans: You don't need to write #strict 2 at the start of each script. All scripts are considered to be in strict 2 style
  • If you need multiple statements in a block, use one (if (...) { foo(); bar(); })! Avoid constructs like if (...) foo() && bar(); or if (...) Or(foo(), bar());