Talk:Function Index: Difference between revisions

From Vendetta Lua
Jump to navigationJump to search
No edit summary
 
(5 intermediate revisions by 2 users not shown)
Line 1: Line 1:
= Document Convention =
= Document Convention =
would be nice if these guidlines were followed when editing or adding entries. I like consistency. I wouldn't mind suggestions how to improve them though. Escpecially the way tables are handled may not be butlletproof cause lua tables can be abused in so many ways.
Would be nice if these guidlines were followed when editing or adding entries. I like consistency.
 
I wouldn't mind suggestions how to improve them though. Escpecially the way tables are handled may not be butlletproof cause lua tables can be abused in so many ways.


use one page per table
use one page per table
if a section of a page may have inaccuracies it should be marked in a way. I use (?)<br>
 
if a section of a page may have inaccuracies it should be marked in a way. I use (?)
 
every table is subdivided into the sections "Functions", "Tables", "Variables"
every table is subdivided into the sections "Functions", "Tables", "Variables"
== Here be Dragons ==
One of the issues I have with function conventions is that there's a lot of functions which are mostly self explanatory, and on top of that- the whole document-per-function crap is a lot of extra goop. If you have the return values in the definition, why do you have a return section? I'd like to get rid of the -> blah crap. The headers are sort of extra too.
Basically, I'd do it like this:
=== RegisterUserCommand ===
RegisterUserCommand(string commandname, func callback, var data)<br><br>
Makes "/commandname data" in VO chat call function callback with data as the argument.<br>
Returns nil
=== IsGroupMember ===
IsGroupMember(int charid)<br><br>
Checks if the player with character ID charid is in your group.<br>
Returns true if player charid is in your group, false otherwise.
[[User:Konata|Konata]] 01:40, 8 July 2007 (EDT)
cause it's easier to read and make changes without having to parse or rewrite some huge ass text block when everything is clearly divided. I'd have probbaly given up after the first dozen or so if I had tried to write halfway comprehensible full description everytime. it gets interesting when you have to describe of something like this thing [[Function_Index#GetCharacterInfo]]
Maybe the empty sections are a bit redundant but that's cause I c&p'ed most functions from some template cutting out empty sections seemed like a waste of time.


== Functions ==
== Functions ==
Line 20: Line 43:


'''Returns'''<br>
'''Returns'''<br>
'''ret''' and outputstring
'''ret''' an outputstring


'''Example'''<br>
'''Example'''<br>
Line 33: Line 56:
to the right specify all return values and their types. if there are multiple return values with the same type, subsequent types may be left out.<br>
to the right specify all return values and their types. if there are multiple return values with the same type, subsequent types may be left out.<br>
Example: ExampleFunction(int in) -> string blab blub int blob<br>
Example: ExampleFunction(int in) -> string blab blub int blob<br>
this function returns two arguments two of type string and one of type int<br>
this function returns has one argument of type int, two return values of type string and one of type int<br>


valid types are:<br>
valid types are:<br>
Line 43: Line 66:
arrays are defined using {type element1 ..} element1 is a non literal identifier representing all array elements, type is the type of the value <br>
arrays are defined using {type element1 ..} element1 is a non literal identifier representing all array elements, type is the type of the value <br>


{identifier} may be used to specify a table with undefined contents or layouts not covered by above rules, its content should be descrbed in the arguments or returns sections  
{identifier} may be used to specify a table with undefined contents or layouts not covered by above rules, its content should be descrbed in the arguments or returns sections


=== Description ===
=== Description ===

Latest revision as of 07:59, 8 July 2007

Document Convention

Would be nice if these guidlines were followed when editing or adding entries. I like consistency.

I wouldn't mind suggestions how to improve them though. Escpecially the way tables are handled may not be butlletproof cause lua tables can be abused in so many ways.

use one page per table

if a section of a page may have inaccuracies it should be marked in a way. I use (?)

every table is subdivided into the sections "Functions", "Tables", "Variables"

Here be Dragons

One of the issues I have with function conventions is that there's a lot of functions which are mostly self explanatory, and on top of that- the whole document-per-function crap is a lot of extra goop. If you have the return values in the definition, why do you have a return section? I'd like to get rid of the -> blah crap. The headers are sort of extra too.

Basically, I'd do it like this:

RegisterUserCommand

RegisterUserCommand(string commandname, func callback, var data)

Makes "/commandname data" in VO chat call function callback with data as the argument.
Returns nil

IsGroupMember

IsGroupMember(int charid)

Checks if the player with character ID charid is in your group.
Returns true if player charid is in your group, false otherwise. Konata 01:40, 8 July 2007 (EDT)


cause it's easier to read and make changes without having to parse or rewrite some huge ass text block when everything is clearly divided. I'd have probbaly given up after the first dozen or so if I had tried to write halfway comprehensible full description everytime. it gets interesting when you have to describe of something like this thing Function_Index#GetCharacterInfo

Maybe the empty sections are a bit redundant but that's cause I c&p'ed most functions from some template cutting out empty sections seemed like a waste of time.

Functions

every function contains the subsections "Definition", "Description", "Arguments", "Returns", "Example"

Example:
Definition:
ExampleFunction(int arg) -> string ret

Description:
Function that takes a number and returns a string

Arguments:
arg an argument

Returns
ret an outputstring

Example
ExampleFunction(1) -> "1 Example"


Definition

defines the function.

to the left of the arrow specify the function, all variables and their expected types. if an argument can have more than one type the type may be left out.

to the right specify all return values and their types. if there are multiple return values with the same type, subsequent types may be left out.
Example: ExampleFunction(int in) -> string blab blub int blob
this function returns has one argument of type int, two return values of type string and one of type int

valid types are:
float, int (since all numbers in lua are float the distinction is a bit arbitary but int should be used where it makes sense), string, table, userdata. these are reserved words that should not be used as identifiers

tables have the format {type element} where element is a literal key. type is the type of the value. (this won't work too well with non human readable keys though but is probably less messy than other systems) numerals in key names should be avoided.

arrays are defined using {type element1 ..} element1 is a non literal identifier representing all array elements, type is the type of the value

{identifier} may be used to specify a table with undefined contents or layouts not covered by above rules, its content should be descrbed in the arguments or returns sections

Description

short description of the function. maybe related functions or documents. quirks ...

Arguments

short description of each argument specified in definition

Returns

short description of each return value specified in definition

Example

illustrative example code

Tables

tbd

Variables

tbd