Difference between revisions of "Guidelines"
(Created page with 'All registered users can edit the wiki, but please follow these guidelines for consistency. If you think the guidelines should be changed, or should contain additional informatio…') |
(→Types) |
||
Line 55: | Line 55: | ||
* Functions | * Functions | ||
* Enums | * Enums | ||
+ | * Supertypes | ||
+ | * Subtypes | ||
* Examples | * Examples | ||
* See Also | * See Also |
Revision as of 22:35, 16 February 2010
All registered users can edit the wiki, but please follow these guidelines for consistency. If you think the guidelines should be changed, or should contain additional information, please don't hesitate to contact Rude.
Contents
Purpose
The main purposes of the wiki are as follows.
- To document the LÖVE API, and provide tutorials.
- To provide information about games and libraries using LÖVE.
That said, it is fully allowed to add information about other things which fall way outside these categories.
If you would like to make major changes in the wiki, like deploying a new structure for built-in types, for example; don't do it. You must talk to Rude first, otherwise there's a high chance your changes will be reverted.
Name Conflics
To avoid too much parenthesized URLs, documentation pages have plain titles without prefixes or suffixes. For instance, the type Image can be referred to externally as http://love2d.org/wiki/Image.
This may occasionally lead to name conflicts, in which case the documentation page will always win. If you create a game called Awesome, and LÖVE later decides to expose a type called Awesome (not completely unlikely), then your game will be moved to another title.
Style
If you're talking about types built into LÖVE, link to them. For instance, Image is an object which can be displayed on screen.
When referring to variables and code inside a regular sentence, use the <code> tag to improve the reading experience. For instance: when you add foo
and bar
, the result is foobar
.
Documentation
Documentation pages must follow the same structure if the documentation is to be usable.
All documentation pages must have a semantic link to their parent in their See Also section. Without this, the item will not appear in the automatic lists throughout the wiki. A semantic link is added like this for a function, type or enum in love.audio:
[[parent::love.audio]]
All documentation pages must also have a semantic, 'list-friendly' description. This is done by adding the following to the bottom of the page:
{{#set:Description=Draws an [[Image]] on screen.}}
Modules
The following 'level 2' headers are allowed, but should only be used if they contain anything.
- Types
- Functions
- Enums
- Examples
- See Also
All modules must be assiciated with Category:Modules.
Types
The following 'level 2' headers are allowed, but again, don't use then and leave them empty.
- Functions
- Enums
- Supertypes
- Subtypes
- Examples
- See Also
All types must be assiciated with Category:Types.
Functions
For functions, all headers are required, except Examples and See Also. This means that if a function returns nothing, it should explicitly say that it returns nothing. The same goes for arguments.
Similarly, if there are no constructors for a certain type (e.g. Contact), this should be explicitly mentioned.
The outer items in the list below are 'level 2' headers, and the inner ones are 'level 3'.
- Constructors
- Function
- Synopsis
- Arguments
- Returns
- Examples
- See Also
If a function has overloads, repeat the 'Function' header for each overload. This is not required for trailing optional arguments; just indicate the default value in parentheses instead.
Arguments and return values should be presented as a definition list, using Template:param.
All functions must be assiciated with Category:Functions.
Enums
For enums, these headers are allowed:
- Constants
- See Also
The constants should be listed as a definition list.
All enums must be associated with Category:Enums.
Games
For games, you can choose your own structure, but you should always add two semantic properties to the page:
{{#set:LOVE Version=0.6.1}} {{#set:Description=A short description of your game.}}
Also, put your game in Category:Games to make it appear automatically in the Games page. It is also recommended that you provide screenshots of your game.
Libraries
No strict rules, but as for games, you should add these semantic properties:
{{#set:LOVE Version=0.6.1}} {{#set:Description=A short description of your library.}}
Put your library in Category:Libraries to make it appear automatically in on the Libraries page.