Skip to content

INPStarfall/Starfall

Folders and files

NameName
Last commit message
Last commit date
Dec 23, 2014
Jun 22, 2016
Jul 24, 2016
Jul 24, 2016
Jun 12, 2015
Feb 3, 2014
Jun 5, 2014
Jun 5, 2012
Jan 3, 2012
Sep 7, 2015
Oct 28, 2012

Repository files navigation

Starfall Scripting Environment

Note: Links are subject to change.

Contributor Information

If you want to contribute to Starfall, you are required to abide by these sets of rules, to make developing Starfall a pleasant experience for everyone and to maintain the quality of the codebase.

Commit message guidelines

Codestyle guidelines

  • No GLua-specific syntax.
    • E.g. don't use //, /**/, &&, ||, etc.
  • Use tabs for indentation, don't use spaces or other whitespace characters.
  • Use LuaDoc-style comments on external user API functions and libraries. Use reasonable documentation for internal API functions and libraries.
  • Add comments when code functionality is not clear or when the purpose of the code is not obvious.
  • Function and variable names are supposed to be in camelCase, constructor functions, however, are supposed to be in CamelCase.
  • No parentheses around conditionals used for program logic.
    • E.g. if conditions/loop headers, unless absolutely necessary.
  • Use spaces between parentheses and their enclosing body.
    • E.g. print( "Hello" ) & function f ( args ) & f( args ).
  • Use spaces after commas, as well as semicolons.
    • E.g. f( a1, a2, a3 ); f2( a1, a2, a3 ).
  • Use spaces between square braces and their enclosing body.
    • E.g. _deserialize[ lastType ]( s, i, len ) & tbl[ 5 ] = "bob".
  • Use spaces between curly braces and their enclosing body, it is also acceptable to use a newline with appropriate indentation instead. ( See table literal multi-line example below. )
    • E.g local tbl = { "Hi", 2, var }
  • Table literals must be delimited by commas which proceed their values. The last value must not have a proceeding comma.
    • E.g ``` local tbl2 = { "Multi-line", 2, lastVal }

       ```
      
  • Use spaces before the argument list of a function definition.
    • E.g. function func ( var1, var2 ).
  • Use spaces before any unary operator; before and after any binary operator.
    • E.g. local var = 5 + 3 and local var2 = -var + 3.
  • Use of one-liners/ single-line multi-statements is discouraged.
    • E.g. var = 5; var2 = 10; var3 = 15.
  • Do not use semicolons at the end of statements, unless required to separate single-line multi-statements.
  • Short circuiting, a = b and c or d, is only permitted if used as a ternary operator. Do not use it for program logic.
    • E.g. Good: print( a and "Hello" or "Hi" ); Bad: a and print("Hello") or print("Hi");

Release strategy

  • We are using Semantic Versioning in the format of Major.Minor.Sub-minor.
    • E.g. 2.0.5.
  • Only changes in major version can break compatibility, backwards compatibility is guaranteed within the same major version.
    • E.g. 2.x.x set will always be cross-compatible.
  • Functions can be deprecated between minor versions and will then be removed in the next major release.
    • E.g function helloWorld() may become deprecated between 2.0.0 and 2.1.0 and will be removed in 3.0.0.
  • Branch naming will follow Major.Minor.
  • Minor versions will belong in a branch specifically for that release. The leading commit will be tagged upon release.
  • When Hotfixes and patches are required, they will be added to the branch for that release and tagged.
  • Once a branch is released, features cannot be added to it.