Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Next revision
Previous revision
lua_conventions [2015/02/04 20:18]
dean4devil created
lua_conventions [2019/08/06 00:02] (current)
payonel
Line 1: Line 1:
- * Be consistent. +Lua Code Conventions 
- * Indent using spaces, two wide. Do indent properly. +============================== 
- * Try to limit width of the code to 80 chars. + 
- * Don't add spaces between braces/​brackets and what's in them. +  * Be consistent. 
- * Do use brackets in functions calls even if it's not necessary. +  * Indent using spaces, two wide. Do indent properly. 
- * Name variables for what they are, don't include type markers in them, i.e. do not use Hungarian notation. +  * Try to limit width of the code to 80 chars. 
- * Nice to have: sort your requires alphabetically (OCD!) +  * Don't add spaces between braces/​brackets and what's in them. 
- ​* ​Only comment ​if it's something complicated/​non obviousKeep in mind that comments increase ​file size, which increases the amount ​of RAM required to run your program! +  * Do use brackets in functions calls even if it's not necessary. 
- * If you have to validate arguments, use the built-in checkArg method. Homogenous error messages are a good thing! Its usage is checkArg(n, value, type1, ...), where n is the number of the argument, value is the value of the argument and type1 and so on are the allowed types for the argument, as retrieved via type(value). The number is used in the error message like so: "bad argument #n (type1 expected, got type(value))"​. So for example, to require the first argument to be a number you'd do checkArg(1, arg, "​number"​).+  * Name variables for what they are, don't include type markers in them, i.e. do not use Hungarian notation. 
 +  * Nice to have: sort your requires alphabetically (OCD!) 
 +  Feel free to comment ​your codeAny additional memory needed to load your file due to heavy use of comments is released soon after loading is complete. 
 +  * If you have to validate arguments, use the built-in checkArg method. Homogenous error messages are a good thing! Its usage is checkArg(n, value, type1, ...), where n is the number of the argument, value is the value of the argument and type1 and so on are the allowed types for the argument, as retrieved via type(value). The number is used in the error message like so: "bad argument #n (type1 expected, got type(value))"​. So for example, to require the first argument to be a number you'd do checkArg(1, arg, "​number"​).
  
 Bad Code: Bad Code:
-<​code>​+<​code ​lua>
 function f(sArg1 , ... ) function f(sArg1 , ... )
    ​assert(type(sArg1)== "​string",​ "me wants a strign!"​)    ​assert(type(sArg1)== "​string",​ "me wants a strign!"​)
Line 25: Line 28:
  
 Good Code: Good Code:
-<​code>​+<​code ​lua>
 function f(name, ...) function f(name, ...)
   checkArg(1, name, "​string"​)   checkArg(1, name, "​string"​)
Line 39: Line 42:
 end end
 </​code>​ </​code>​
 +
 +Contents
 +-----------
 +{{page>:​contents&​noheader&​noeditbutton&​nouser&​nofooter}}