Skip to content

INPStarfall/Starfall

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.