C4Script Style Guidelines - Revision history

Maikel at 18:25, 4 February 2017

2017-02-04T18:25:53Z

← Older revision		Revision as of 18:25, 4 February 2017
Line 59:		Line 59:
	====Naming prefixes for IDs====		====Naming prefixes for IDs====
	* for libraries, icons and GUI elements: <tt>Library_</tt>, <tt>Icon_</tt>, <tt>GUI_*</tt>		* 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_</~~code~~>, <tt>Environment_*</tt>		* for goals, rules and environment objects: <tt>Goal_</tt>, <tt>Rule_</tt>, <tt>Environment_*</tt>
	* for spells: <tt>Magic_*</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		* 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

Maikel: /* Naming conventions */

2017-02-04T18:25:13Z

Naming conventions

← Older revision		Revision as of 18:25, 4 February 2017
Line 38:		Line 38:
	* for functions use <tt>CamelCase()</tt>		* for functions use <tt>CamelCase()</tt>
	* for static constants use <tt>PREFIX_Identifier</tt>		* for static constants use <tt>PREFIX_Identifier</tt>
	* ~~for~~ new style effects ~~use~~ <tt>FxNewStyleEffect</tt>		* Prepend new style effects with <tt>Fx</tt> like <tt>FxNewStyleEffect</tt>

	====Indents, braces and spaces====		====Indents, braces and spaces====

Maikel at 18:24, 4 February 2017

2017-02-04T18:24:40Z

← Older revision		Revision as of 18:24, 4 February 2017
Line 10:		Line 10:
	*/		*/

	local some_variable;		local some_variable;

	/** ''Explanation of what the function does''		/** ''Explanation of what the function does''
Line 38:		Line 38:
	* for functions use <tt>CamelCase()</tt>		* for functions use <tt>CamelCase()</tt>
	* for static constants use <tt>PREFIX_Identifier</tt>		* for static constants use <tt>PREFIX_Identifier</tt>
			* for new style effects use <tt>FxNewStyleEffect</tt>

	====Indents, braces and spaces====		====Indents, braces and spaces====

Zapper: Added conventions about access specifiers; also cleanups

2015-03-29T06:21:40Z

Added conventions about access specifiers; also cleanups

← Older revision		Revision as of 06:21, 29 March 2015
Line 33:		Line 33:
	=== In words ===		=== In words ===

	Naming conventions:		====Naming conventions====
	* generally, use meaningful identifiers which are self explanatory: e.g. <~~code~~>weapon_strength</~~code~~> rather than <~~code~~>iStr</~~code~~>		* generally, use meaningful identifiers which are self explanatory: e.g. <tt>weapon_strength</tt> rather than <tt>iStr</tt>
	* don't use hungarian notation, preferably use <~~code~~>lowercase_separated_by_underscores</~~code~~> ~~for variables~~		* for variables don't use hungarian notation, preferably use <tt>lowercase_separated_by_underscores</tt>
	* use <~~code~~>CamelCase()</~~code~~> ~~for functions~~		* for functions use <tt>CamelCase()</tt>
	* use <~~code~~>PREFIX_Identifier</~~code~~> ~~for static constants~~		* for static constants use <tt>PREFIX_Identifier</tt>

	Indents, braces and spaces:		====Indents, braces and spaces====
	* indent code with one tab		* indent code with one tab
	* use the braces on own lines on the same indent level as the control structure / function declaration		* use the braces on own lines on the same indent level as the control structure / function declaration
Line 47:		Line 47:
	* function names are not followed by space, commas are		* function names are not followed by space, commas are

	Comments and Documentation:		====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.

			====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		* 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 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		* please use Javadoc-like syntax when documenting your code so that a reference can be automatically created from it later

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

	Misc:		====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		* 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 (<~~code~~>if (...) { foo(); bar(); }</~~code~~>)! Avoid constructs like <~~code~~>if (...) foo() && bar();</~~code~~> or <~~code~~>if (...) Or(foo(), bar());</~~code~~>		* 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>

Newton: - :LongIDs

2011-01-07T14:40:32Z

- :LongIDs

← Older revision		Revision as of 14:40, 7 January 2011
Line 22:		Line 22:
	{		{
	some_variable++;		some_variable++;
	CreateObject(:Goal_Melee);		CreateObject(Goal_Melee);
	}		}

Maikel: /* In words */

2010-10-29T21:30:51Z

In words

← Older revision		Revision as of 21:30, 29 October 2010
Line 35:		Line 35:
	Naming conventions:		Naming conventions:
	* generally, use meaningful identifiers which are self explanatory: e.g. <code>weapon_strength</code> rather than <code>iStr</code>		* generally, use meaningful identifiers which are self explanatory: e.g. <code>weapon_strength</code> rather than <code>iStr</code>
	* don't use hungarian notation, preferably use <code>lowercase_separated_by_underscores</code>		* don't use hungarian notation, preferably use <code>lowercase_separated_by_underscores</code> for variables
	* use <code>CamelCase()</code> for functions		* use <code>CamelCase()</code> for functions
	* use <code>PREFIX_Identifier</code> for static constants		* use <code>PREFIX_Identifier</code> for static constants
Line 44:		Line 44:
	* <code>{...}</code> braces are not required for single line statements but can be added if it improves readability		* <code>{...}</code> braces are not required for single line statements but can be added if it improves readability
	* use spaces between operators like +, -, *, /, &&, \|\| etc.		* 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

	Comments and Documentation:		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		* 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 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		* please use Javadoc-like syntax when documenting your code so that a reference can be automatically created from it later

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

Newton: ->javadoc

2010-08-21T23:17:28Z

->javadoc

← Older revision		Revision as of 23:17, 21 August 2010
Line 1:		Line 1:
	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. Please adhere to this example if you edit or add new scripts:		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 ===		=== Example ===

	/*--		/**
	''Object title''		''Object title''
	~~Author:~~ ''~~Author(s)~~''		''Description, including implementation details that might be interesting for other scripters''

	''~~Description, including implementation details that might be interesting for other scripters~~''		@author ''Author(s)''
	--*/		*/

	local some_variable;		local some_variable;

	// ''Explanation of what the function does''		/** ''Explanation of what the function does''
	public func DoSomething()		@param foo ''What the parameter foo is''
			@return ''What comes out of this function''
			*/
			public func DoSomething(int foo)
	{		{
	~~var foo = 1;~~
	// ''implementation commentars''		// ''implementation commentars''
	if (foo == DIR_Left)		if (foo == DIR_Left)
Line 43:		Line 45:
	* use spaces between operators like +, -, *, /, &&, \|\| etc.		* use spaces between operators like +, -, *, /, &&, \|\| etc.

	Comments:		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		* 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 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:		Naming prefixes for IDs:

Sven2: /* In words */

2010-04-03T16:19:07Z

In words

← Older revision		Revision as of 16:19, 3 April 2010
Line 55:		Line 55:
	Misc:		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		* 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 (<code>if (...) { foo(); bar(); }</code>)! Avoid constructs like <code>if (...) foo() && bar();</code> or <code>if (...) Or(foo(), bar());</code>

Newton: /* In words */

2010-03-08T17:06:37Z

In words

← Older revision		Revision as of 17:06, 8 March 2010
Line 51:		Line 51:
	* for goals, rules and environment objects: <code>Goal_</code>, <code>Rule_</code>, <code>Environment_*</code>		* for goals, rules and environment objects: <code>Goal_</code>, <code>Rule_</code>, <code>Environment_*</code>
	* for spells: <code>Magic_</code>		* for spells: <code>Magic_</code>
	* ~~subobjects of other~~ objects should prefix their parent object name. e.g. <code>~~Shovel_Dust~~</code>		* objects which are exclusively used by their parent objects should prefix their parent object name. e.g. <code>ParkourCheckpoint</code> for a checkpoint of the parkour goal
	* prefixes for ~~scenario-local objects and addon-packs~~

	Misc:		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		* 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

Newton: #strict2

2010-03-06T00:43:59Z

#strict2

← Older revision		Revision as of 00:43, 6 March 2010
Line 53:		Line 53:
	* subobjects of other objects should prefix their parent object name. e.g. <code>Shovel_Dust</code>		* subobjects of other objects should prefix their parent object name. e.g. <code>Shovel_Dust</code>
	* prefixes for scenario-local objects and addon-packs		* prefixes for scenario-local objects and addon-packs

			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