Skip to content

Style Definitions🔗

To ensure consistency across the documentation, we use the following style definitions.

Reference Lists🔗

There are multiple listings of reference material regarding actions, conditions, or other aspects of the plugin. To simplify the process of maintaining these lists, we use the following style definition.

Example

Example🔗

Context:
Syntax: example <param1> [param2] {param3} +[...]
Description: An example action.

This description is used to provide a brief explanation of the action if it is not obvious from short description above. It may also be used to provide additional information about the parameters or special behaviors of the action.

Parameter Type Explanation
param1
[Number]		 Required What does this parameter do?
param2
[String]		 Optional
[Null]		 What does this parameter do?
param3
[Boolean]		 Flag
[false, true]		 What does this parameter do?
+[...]
[String]		 Additionals What do these parameters do?
Examples
actions:
  exapl1: "example 55 param2:Test param3:false"
  exapl2: "example 55 param2:Test param3"
  exapl3: "example 55 param2:Test"
  exapl4: "example 55 param3"
  exapl5: "example 55"
  exapl6: "example 55 param2:Test param3:false +myAdditionalParam:AnyValue"

Make sure the style matches using the following checklists:

Description
  • The headline of the reference list element should be the precise name of the action, condition, etc.
  • The element should be inserted into the list in alphabetical order, making it easy to find.
  • The context should be defined according to the implementation. Make sure to use the correct snippet.
  • The syntax should be defined according to the implementation. Use <name> for required parameters, [name] for optional and {name} for flag parameters. +[...] should be used for additional parameters.
  • The short description should be written in a way that is easy to understand.
  • The longer description may be used to provide additional information about the parameters or special behaviors of the element, but may be omitted if it is not necessary.
Parameters
  • If the element has at least one parameter, there has to be a table listing the parameters. If the element has no parameters, the table may be omitted.
  • The parameters should be listed in identical order as they are defined in the syntax above.
  • Each parameters name should be defined in the first column and the expected data type after a linebreak inside [] brackets.
  • Each parameters type should be defined in the second column and its defaults after a linebreak inside [] brackets.
  • The explaination of each parameter should be written in a way that is precise yet easy to understand.
Examples
  • Examples are a good way to show how the element is used and should be included at the end of the elements scope.
  • There does not need to be an example for every possible combination of parameters but they should visualize the usage of the element.
  • All examples should be shown inside the matching section in the script, e.g. actions for actions.
  • The examples section may never be empty or omitted
  • The examples section should always have a reasonable amount of examples.
  • All examples preferably have readable names if possible.
Additional Information
  • All important keywords should be linked to the Definition Encyclopedia.
  • Attach all relevant glossary entries to the page if there is something missing.