#==============================================================================
** 4.0 - Coding Standards
To be compliant with the SDK, a script must comply with the following
coding standards:
4.1 - Commenting
4.2 - Classes
4.3 - Variables
4.4 - Aliases
4.5 - Strings
4.6 - Line Length
4.7 - White Space
4.8 - Constants
4.9 - Parentheses
4.10 - Versions
#------------------------------------------------------------------------------
* 4.1 - Commenting
Scripts must begin with the following header :
#==============================================================================
# ** Script Name
#------------------------------------------------------------------------------
# Your Name
# Version
# Date
# SDK Version : (SDK Version Number) - Parts #s
#==============================================================================
All classes and methods must have a comment describing the process or what
was added. All code added to methods that can not be aliased must be
formatted as follows:
#----------------------------------------------------------------------------
# Begin Script Name Edit
#----------------------------------------------------------------------------
{Code}
#----------------------------------------------------------------------------
# End Script Name Edit
#----------------------------------------------------------------------------
Single line comments should precede the described block of code and should be
indented at the same level. Code that is not self-documenting should be
commented.
However, very short comments can appear on the same line as the described
code, but should be shifted far enough to separate them from the statements.
If more than one short comment appears in a chunk of code, they should all be
indented to the same tab setting. Attribute declarations should always have a
trailing comment.
#------------------------------------------------------------------------------
* 4.2 - Classes
All classes must be named consistently with the default code, namely:
Data - Any class that defines database information
Game - Any class that defines specific game data for specific session
Sprite - Any class that defines a specialized sprite class
Spriteset - Any class that defines multiple sprites
Window - Any class that defines a specialized window class
Arrow - Any class that defines a specialized arrow class
Scene - Any class that defines a specialized scene
#------------------------------------------------------------------------------
* 4.3 - Variables
All variable names must be reasonably descriptive. Use of class and global
variables should be limited. Any variable used by the default system can not
have its use changed.
#------------------------------------------------------------------------------
* 4.4 - Aliases
Aliasing a method is preferable to overriding it; an alias should be used
whenever possible to increase compatibility with other scripts. All aliased
method names must either be logged, or by using the alias_method method in
class Module. All alias names must have the following format:
alias new_method_name old_method_name
SDK.log_alias(:class_name, :old_method_name, :new_method_name)
- or -
alias_method :new_method_name, :old_method_name
* Format for New Method Name should be:
yourname_scriptname_classname_methodname / yourname_scriptname_methodname
** Note : When Aliasing the same method in parent / child-class, it is
required for you to put class name in the alias naming.
#------------------------------------------------------------------------------
* 4.5 ? Strings
Strings should normally be defined with single quotes ('example'); this
decreases the processing time of the engine. Double quotes are useful when
using the following features:
a) substitutions, i.e. sequences that start with a backslash character
(e.g. \n for the newline character)
b) expression interpolation, i.e. #{ expression } is replaced by the value
of expression
#------------------------------------------------------------------------------
* 4.6 - Line Length
Lines should not cause the the viewer to have to scroll sideways to view them
in the script editor. When the line needs to be broken, it should follow the
following guidelines, in preferential order:
Break after a comma.
Break before an operator.
Prefer higher-level breaks to lower-level breaks.
Align the new line with the beginning of the expression at the same level
on the previous line.
If the above rules lead to confusing code or to code that?s squished up
against the right margin, just indent 4 spaces instead.
#------------------------------------------------------------------------------
* 4.7 - White Space
A blank line(s) should be used in the following places:
Between sections of a source file
Between class and module definitions
Between attributes and the class definition
Between methods
Between the local variables in a method and its first statement
Before a block or single-line comment
Between logical sections inside a method to improve readability
Blank spaces should be used in the following places:
A keyword followed by a parenthesis, e.g. if (some_boolean_statements)
After commas in argument lists, e.g. def method (arg1, arg2, ...)
All binary operators except '.', e.g. a + b; c = 1
#------------------------------------------------------------------------------
* 4.8 - Constants
Numercial values that are used constantly and have the same purpose
for being used, is encouraged to be made a constant value instead of being
hard coded. Also if a numericial value has a important function that can be
changed then it is also encouraged for it to be made a constant.
#------------------------------------------------------------------------------
* 4.9 - Parentheses
It is generally a good idea to use parentheses liberally in expressions
involving mixed operators to avoid operator precedence problems. Even if
the operator precedence seems clear to you, it might not be to others -? you
shouldn?t assume that other programmers know precedence as well as you do.
#------------------------------------------------------------------------------
* 4.10 - Versions
You are required to document the script with the current version. Here is a
general guideline to recording this. (Thanks to Ccoa)
Format : A.BC (A.B.C is fine except when logging)
A = Main Version or Rewrites
B = Additions or Modifications
C = Bug Fixes
Due to the version checking, A.B.C will result in an error if used to log
your script. Please use the A.BC method when logging script.
