{"id":13897068,"url":"https://github.com/luarocks/lua-style-guide","last_synced_at":"2025-10-08T14:09:21.121Z","repository":{"id":41262865,"uuid":"93564353","full_name":"luarocks/lua-style-guide","owner":"luarocks","description":"Lua Style Guide, as used by LuaRocks","archived":false,"fork":false,"pushed_at":"2019-04-07T13:11:55.000Z","size":16,"stargazers_count":329,"open_issues_count":0,"forks_count":31,"subscribers_count":6,"default_branch":"master","last_synced_at":"2025-09-07T04:38:36.458Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":null,"has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/luarocks.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null}},"created_at":"2017-06-06T21:12:29.000Z","updated_at":"2025-09-03T23:10:31.000Z","dependencies_parsed_at":"2022-08-02T13:16:47.684Z","dependency_job_id":null,"html_url":"https://github.com/luarocks/lua-style-guide","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/luarocks/lua-style-guide","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/luarocks%2Flua-style-guide","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/luarocks%2Flua-style-guide/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/luarocks%2Flua-style-guide/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/luarocks%2Flua-style-guide/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/luarocks","download_url":"https://codeload.github.com/luarocks/lua-style-guide/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/luarocks%2Flua-style-guide/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":278956330,"owners_count":26075221,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","status":"online","status_checked_at":"2025-10-08T02:00:06.501Z","response_time":56,"last_error":null,"robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":true,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-08-06T18:03:19.624Z","updated_at":"2025-10-08T14:09:21.068Z","avatar_url":"https://github.com/luarocks.png","language":null,"funding_links":[],"categories":["Others","Resources"],"sub_categories":[],"readme":"\n# Lua Style Guide\n\nThis style guides lists the coding conventions used in the\n[LuaRocks](http://github.com/luarocks/luarocks) project. It does not claim to\nbe the best Lua coding style in the planet, but it is used successfully in a\nlong-running project, and we do provide rationale for many of the design\ndecisions listed below.\n\nThe list of recommendations in this document was based on the ones mentioned\nin the following style guides: (sometimes copying material verbatim, sometimes\ngiving the opposite advice! :) )\n\n* https://github.com/Olivine-Labs/lua-style-guide/\n* https://github.com/zaki/lua-style-guide\n* http://lua-users.org/wiki/LuaStyleGuide\n* http://sputnik.freewisdom.org/en/Coding_Standard\n* https://gist.github.com/catwell/b3c01dbea413aa78675740546dfd5ce2\n\n## Indentation and formatting\n\n* Let's address the elephant in the room first. LuaRocks is indented with 3 spaces.\n\n```lua\nfor i, pkg in ipairs(packages) do\n   for name, version in pairs(pkg) do\n      if name == searched then\n         print(version)\n      end\n   end\nend\n```\n\n\u003e **Rationale:** There is no agreement in the Lua community as for indentation, so\n3 spaces lies nicely as a middle ground between the 2-space camp and the\n4-space camp. Also, for a language that nests with `do`/`end` blocks, it\nproduces pleasant-looking block-closing staircases, as in the example above.\n\n* One should not use tabs for indentation, or mix it with spaces.\n\n* Use LF (Unix) line endings.\n\n## Documentation\n\n* Document function signatures using\n[LDoc](https://stevedonovan.github.io/ldoc/). Specifying typing information\nafter each parameter or return value is a nice plus.\n\n```lua\n--- Load a local or remote manifest describing a repository.\n-- All functions that use manifest tables assume they were obtained\n-- through either this function or load_local_manifest.\n-- @param repo_url string: URL or pathname for the repository.\n-- @param lua_version string: Lua version in \"5.x\" format, defaults to installed version.\n-- @return table or (nil, string, [string]): A table representing the manifest,\n-- or nil followed by an error message and an optional error code.\nfunction manif.load_manifest(repo_url, lua_version)\n   -- code\nend\n```\n\n* Use `TODO` and `FIXME` tags in comments. `TODO` indicates a missing feature\nto be implemented later. `FIXME` indicates a problem in the existing code\n(inefficient implementation, bug, unnecessary code, etc).\n\n```lua\n-- TODO: implement method\nlocal function something()\n   -- FIXME: check conditions\nend\n```\n\n* Prefer LDoc comments over the function that explain _what_ the function does\nthan inline comments inside the function that explain _how_ it does it. Ideally,\nthe implementation should be simple enough so that comments aren't needed. If\nthe function grows complex, split it into multiple functions so that their names\nexplain what each part does.\n\n## Variable names\n\n* Variable names with larger scope should be more descriptive than those with\nsmaller scope. One-letter variable names should be avoided except for very\nsmall scopes (less than ten lines) or for iterators.\n\n* `i` should be used only as a counter variable in for loops (either numeric for\nor `ipairs`).\n\n* Prefer more descriptive names than `k` and `v` when iterating with `pairs`,\nunless you are writing a function that operates on generic tables.\n\n* Use `_` for ignored variables (e.g. in for loops:)\n\n```lua\nfor _, item in ipairs(items) do\n   do_something_with_item(item)\nend\n```\n\n* Variables and function names should use `snake_case`.\n\n```lua\n-- bad\nlocal OBJEcttsssss = {}\nlocal thisIsMyObject = {}\nlocal c = function()\n   -- ...stuff...\nend\n\n-- good\nlocal this_is_my_object = {}\n\nlocal function do_that_thing()\n   -- ...stuff...\nend\n```\n\n\u003e **Rationale:** The standard library uses lowercase APIs, with `joinedlowercase`\nnames, but this does not scale too well for more complex APIs. `snake_case`\ntends to look good enough and not too out-of-place along side the standard\nAPIs.\n\n* When doing OOP, classes should use `CamelCase`. Acronyms (e.g. XML) should\nonly uppercase the first letter (`XmlDocument`). Methods use `snake_case` too.\nIn LuaRocks, this is used in the `Api` object in the `luarocks.upload.api`\nmodule.\n\n```lua\nfor _, name in pairs(names) do\n   -- ...stuff...\nend\n```\n\n* Prefer using `is_` when naming boolean functions:\n\n```lua\n-- bad\nlocal function evil(alignment)\n   return alignment \u003c 100\nend\n\n-- good\nlocal function is_evil(alignment)\n   return alignment \u003c 100\nend\n```\n\n* `UPPER_CASE` is to be used sparingly, with \"constants\" only.\n\n\u003e **Rationale:** \"Sparingly\", since Lua does not have real constants. This\nnotation is most useful in libraries that bind C libraries, when bringing over\nconstants from C.\n\n* Do not use uppercase names starting with `_`, they are reserved by Lua.\n\n## Tables\n\n* When creating a table, prefer populating its fields all at once, if possible:\n\n```lua\nlocal player = {\n   name = \"Jack\",\n   class = \"Rogue\",\n}\n```\n\n* You can add a trailing comma to all fields, including the last one.\n\n\u003e **Rationale:** This makes the structure of your tables more evident at a glance.\nTrailing commas make it quicker to add new fields and produces shorter diffs.\n\n* Use plain `key` syntax whenever possible, use `[\"key\"]` syntax when using names\nthat can't be represented as identifiers and avoid mixing representations in\na declaration:\n\n```lua\ntable = {\n   [\"1394-E\"] = val1,\n   [\"UTF-8\"] = val2,\n   [\"and\"] = val2,\n}\n```\n\n## Strings\n\n* Use `\"double quotes\"` for strings; use `'single quotes'` when writing strings\nthat contain double quotes.\n\n```lua\nlocal name = \"LuaRocks\"\nlocal sentence = 'The name of the program is \"LuaRocks\"'\n```\n\n\u003e **Rationale:** Double quotes are used as string delimiters in a larger number of\nprogramming languages. Single quotes are useful for avoiding escaping when\nusing double quotes in literals.\n\n## Line lengths\n\n* There are no hard or soft limits on line lengths. Line lengths are naturally\nlimited by using one statement per line. If that still produces lines that are\ntoo long (e.g. an expression that produces a line over 256-characters long,\nfor example), this means the expression is too complex and would do better\nsplit into subexpressions with reasonable names.\n\n\u003e **Rationale:** No one works on VT100 terminals anymore. If line lengths are a proxy\nfor code complexity, we should address code complexity instead of using line\nbreaks to fit mind-bending statements over multiple lines.\n\n## Function declaration syntax\n\n* Prefer function syntax over variable syntax. This helps differentiate between\nnamed and anonymous functions.\n\n```lua\n-- bad\nlocal nope = function(name, options)\n   -- ...stuff...\nend\n\n-- good\nlocal function yup(name, options)\n   -- ...stuff...\nend\n```\n\n* Perform validation early and return as early as possible.\n\n```lua\n-- bad\nlocal function is_good_name(name, options, arg)\n   local is_good = #name \u003e 3\n   is_good = is_good and #name \u003c 30\n\n   -- ...stuff...\n\n   return is_good\nend\n\n-- good\nlocal function is_good_name(name, options, args)\n   if #name \u003c 3 or #name \u003e 30 then\n      return false\n   end\n\n   -- ...stuff...\n\n   return true\nend\n```\n\n## Function calls\n\n* Even though Lua allows it, do not omit parenthesis for functions that take a\nunique string literal argument. \n\n```lua\n-- bad\nlocal data = get_data\"KRP\"..tostring(area_number)\n-- good\nlocal data = get_data(\"KRP\"..tostring(area_number))\nlocal data = get_data(\"KRP\")..tostring(area_number)\n```\n\n\u003e **Rationale:** It is not obvious at a glace what the precedence rules are\nwhen omitting the parentheses in a function call. Can you quickly tell which\nof the two \"good\" examples in equivalent to the \"bad\" one? (It's the second\none).\n\n* You should not omit parenthesis for functions that take a unique table\nargument on a single line. You may do so for table arguments that span several\nlines.\n\n```lua\nlocal an_instance = a_module.new {\n   a_parameter = 42,\n   another_parameter = \"yay\",\n}\n```\n\n\u003e **Rationale:** The use as in `a_module.new` above occurs alone in a statement,\nso there are no precedence issues.\n\n## Table attributes\n\n* Use dot notation when accessing known properties.\n\n```lua\nlocal luke = {\n   jedi = true,\n   age = 28,\n}\n\n-- bad\nlocal is_jedi = luke[\"jedi\"]\n\n-- good\nlocal is_jedi = luke.jedi\n```\n\n* Use subscript notation `[]` when accessing properties with a variable or if using a table as a list.\n\n```lua\nlocal vehicles = load_vehicles_from_disk(\"vehicles.dat\")\n\nif vehicles[\"Porsche\"] then\n   porsche_handler(vehicles[\"Porsche\"])\n   vehicles[\"Porsche\"] = nil\nend\nfor name, cars in pairs(vehicles) do\n   regular_handler(cars)\nend\n```\n\n\u003e **Rationale:** Using dot notation makes it clearer that the given key is meant\nto be used as a record/object field.\n\n## Functions in tables\n\n* When declaring modules and classes, declare functions external to the table definition:\n\n```lua\nlocal my_module = {}\n\nfunction my_module.a_function(x)\n   -- code\nend\n```\n\n* When declaring metatables, declare function internal to the table definition.\n\n```lua\nlocal version_mt = {\n   __eq = function(a, b)\n      -- code\n   end,\n   __lt = function(a, b)\n      -- code\n   end,\n}\n```\n\n\u003e **Rationale:** Metatables contain special behavior that affect the tables\nthey're assigned (and are used implicitly at the call site), so it's good to\nbe able to get a view of the complete behavior of the metatable at a glance.\n\nThis is not as important for objects and modules, which usually have way more\ncode, and which don't fit in a single screen anyway, so nesting them inside\nthe table does not gain much: when scrolling a longer file, it is more evident\nthat `check_version` is a method of `Api` if it says `function Api:check_version()`\nthan if it says `check_version = function()` under some indentation level.\n\n## Variable declaration\n\n* Always use `local` to declare variables. \n\n```lua\n-- bad\nsuperpower = get_superpower()\n\n-- good\nlocal superpower = get_superpower()\n```\n\n\u003e **Rationale:** Not doing so will result in global variables to avoid polluting\nthe global namespace. \n\n## Variable scope\n\n* Assign variables with the smallest possible scope.\n\n```lua\n-- bad\nlocal function good()\n   local name = get_name()\n\n   test()\n   print(\"doing stuff..\")\n\n   --...other stuff...\n\n   if name == \"test\" then\n      return false\n   end\n\n   return name\nend\n\n-- good\nlocal bad = function()\n   test()\n   print(\"doing stuff..\")\n\n   --...other stuff...\n\n   local name = get_name()\n\n   if name == \"test\" then\n      return false\n   end\n\n   return name\nend\n```\n\n\u003e **Rationale:** Lua has proper lexical scoping. Declaring the function later means that its\nscope is smaller, so this makes it easier to check for the effects of a variable.\n\n## Conditional expressions\n\n* False and nil are falsy in conditional expressions. Use shortcuts when you\ncan, unless you need to know the difference between false and nil.\n\n```lua\n-- bad\nif name ~= nil then\n   -- ...stuff...\nend\n\n-- good\nif name then\n   -- ...stuff...\nend\n```\n\n* Avoid designing APIs which depend on the difference between `nil` and `false`.\n\n* Use the `and`/`or` idiom for the pseudo-ternary operator when it results in\nmore straightforward code. When nesting expressions, use parentheses to make it\neasier to scan visually:\n\n```lua\nlocal function default_name(name)\n   -- return the default \"Waldo\" if name is nil\n   return name or \"Waldo\"\nend\n\nlocal function brew_coffee(machine)\n   return (machine and machine.is_loaded) and \"coffee brewing\" or \"fill your water\"\nend\n```\n\nNote that the `x and y or z` as a substitute for `x ? y : z` does not work if\n`y` may be `nil` or `false` so avoid it altogether for returning booleans or\nvalues which may be nil.\n\n## Blocks\n\n* Use single-line blocks only for `then return`, `then break` and `function return` (a.k.a \"lambda\") constructs:\n\n```lua\n-- good\nif test then break end\n\n-- good\nif not ok then return nil, \"this failed for this reason: \" .. reason end\n\n-- good\nuse_callback(x, function(k) return k.last end)\n\n-- good\nif test then\n  return false\nend\n\n-- bad\nif test \u003c 1 and do_complicated_function(test) == false or seven == 8 and nine == 10 then do_other_complicated_function() end\n\n-- good\nif test \u003c 1 and do_complicated_function(test) == false or seven == 8 and nine == 10 then\n   do_other_complicated_function() \n   return false \nend\n```\n\n* Separate statements onto multiple lines. Do not use semicolons as statement terminators.\n\n```lua\n-- bad\nlocal whatever = \"sure\";\na = 1; b = 2\n\n-- good\nlocal whatever = \"sure\"\na = 1\nb = 2\n```\n\n## Spacing\n\n* Use a space after `--`. \n\n```lua\n--bad\n-- good\n```\n\n* Always put a space after commas and between operators and assignment signs:\n\n```lua\n-- bad\nlocal x = y*9\nlocal numbers={1,2,3}\nnumbers={1 , 2 , 3}\nnumbers={1 ,2 ,3}\nlocal strings = { \"hello\"\n                , \"Lua\"\n                , \"world\"\n                }\ndog.set( \"attr\",{\n  age=\"1 year\",\n  breed=\"Bernese Mountain Dog\"\n})\n\n-- good\nlocal x = y * 9\nlocal numbers = {1, 2, 3}\nlocal strings = {\n   \"hello\",\n   \"Lua\",\n   \"world\",\n}\ndog.set(\"attr\", {\n   age = \"1 year\",\n   breed = \"Bernese Mountain Dog\",\n})\n```\n\n* Indent tables and functions according to the start of the line, not the construct:\n\n```lua\n-- bad\nlocal my_table = {\n                    \"hello\",\n                    \"world\",\n                 }\nusing_a_callback(x, function(...)\n                       print(\"hello\")\n                    end)\n\n-- good\nlocal my_table = {\n   \"hello\",\n   \"world\",\n}\nusing_a_callback(x, function(...)\n   print(\"hello\")\nend)\n```\n\n\u003e **Rationale:** This keep indentation levels aligned at predictable places. You don't\nneed to realign the entire block if something in the first line changes (such as\nreplacing `x` with `xy` in the `using_a_callback` example above).\n\n* The concatenation operator gets a pass for avoiding spaces:\n\n```lua\n-- okay\nlocal message = \"Hello, \"..user..\"! This is your day # \"..day..\" in our platform!\"\n```\n\n\u003e **Rationale:** Being at the baseline, the dots already provide some visual spacing.\n\n* No spaces after the name of a function in a declaration or in its arguments:\n\n```lua\n-- bad\nlocal function hello ( name, language )\n   -- code\nend\n\n-- good\nlocal function hello(name, language)\n   -- code\nend\n```\n\n* Add blank lines between functions:\n\n```lua\n-- bad\nlocal function foo()\n   -- code\nend\nlocal function bar()\n   -- code\nend\n\n-- good\nlocal function foo()\n   -- code\nend\n\nlocal function bar()\n   -- code\nend\n```\n\n* Avoid aligning variable declarations:\n\n```lua\n-- bad\nlocal a               = 1\nlocal long_identifier = 2\n\n-- good\nlocal a = 1\nlocal long_identifier = 2\n```\n\n\u003e **Rationale:** This produces extra diffs which add noise to `git blame`.\n\n* Alignment is occasionally useful when logical correspondence is to be highlighted:\n\n```lua\n-- okay\nsys_command(form, UI_FORM_UPDATE_NODE, \"a\",      FORM_NODE_HIDDEN,  false)\nsys_command(form, UI_FORM_UPDATE_NODE, \"sample\", FORM_NODE_VISIBLE, false)\n```\n\n## Typing\n\n* In non-performance critical code, it can be useful to add type-checking assertions\nfor function arguments:\n\n```lua\nfunction manif.load_manifest(repo_url, lua_version)\n   assert(type(repo_url) == \"string\")\n   assert(type(lua_version) == \"string\" or not lua_version)\n\n   -- ...\nend\n```\n\n\u003e **Rationale:** This is a practice adopted early on in the development of LuaRocks\nthat has shown to be beneficial in many occasions.\n\n* Use the standard functions for type conversion, avoid relying on coercion:\n\n```lua\n-- bad\nlocal total_score = review_score .. \"\"\n\n-- good\nlocal total_score = tostring(review_score)\n```\n\n## Errors\n\n* Functions that can fail for reasons that are expected (e.g. I/O) should\nreturn `nil` and a (string) error message on error, possibly followed by other\nreturn values such as an error code.\n\n* On errors such as API misuse, an error should be thrown, either with `error()`\nor `assert()`.\n\n## Modules\n\nFollow [these guidelines](http://hisham.hm/2014/01/02/how-to-write-lua-modules-in-a-post-module-world/) for writing modules. In short:\n\n* Always require a module into a local variable named after the last component of the module’s full name.\n\n```lua\nlocal bar = require(\"foo.bar\") -- requiring the module\n\nbar.say(\"hello\") -- using the module\n```\n\n* Don’t rename modules arbitrarily:\n\n```lua\n-- bad\nlocal skt = require(\"socket\")\n```\n\n\u003e **Rationale:** Code is much harder to read if we have to keep going back to the top\nto check how you chose to call a module.\n\n* Start a module by declaring its table using the same all-lowercase local\nname that will be used to require it. You may use an LDoc comment to identify\nthe whole module path.\n\n```lua\n--- @module foo.bar\nlocal bar = {}\n```\n\n* Try to use names that won't clash with your local variables. For instance, don't\nname your module something like “size”.\n\n* Use `local function` to declare _local_ functions only: that is, functions\nthat won’t be accessible from outside the module.\n\nThat is, `local function helper_foo()` means that `helper_foo` is really local.\n\n* Public functions are declared in the module table, with dot syntax:\n\n```lua\nfunction bar.say(greeting)\n   print(greeting)\nend\n```\n\n\u003e **Rationale:** Visibility rules are made explicit through syntax. \n\n* Do not set any globals in your module and always return a table in the end.\n\n* If you would like your module to be used as a function, you may set the\n`__call` metamethod on the module table instead.\n\n\u003e **Rationale:** Modules should return tables in order to be amenable to have their\ncontents inspected via the Lua interactive interpreter or other tools.\n\n* Requiring a module should cause no side-effect other than loading other\nmodules and returning the module table.\n\n* A module should not have state (this still needs to be fixed for some\nLuaRocks modules). If a module needs configuration, turn it into a factory.\nFor example, do not make something like this:\n\n```lua\n-- bad\nlocal mp = require \"MessagePack\"\nmp.set_integer(\"unsigned\")\n```\n\nand do something like this instead:\n\n```lua\n-- good\nlocal messagepack = require(\"messagepack\")\nlocal mpack = messagepack.new({integer = \"unsigned\"})\n```\n\n* The invocation of require should look like a regular Lua function call, because it is.\n\n```lua\n-- bad\nlocal bla = require \"bla\"\n\n-- good\nlocal bla = require(\"bla\")\n```\n\n\u003e **Rationale:** This makes it explicit that require is a function call and not a keyword. Many other languages employ keywords for this purpose, so having a \"special syntax\" for require would trip up Lua newcomers.\n\n## OOP\n\n* Create classes like this:\n\n```lua\n--- @module myproject.myclass\nlocal myclass = {}\n\n-- class table\nlocal MyClass = {}\n\nfunction MyClass:some_method()\n   -- code\nend\n\nfunction MyClass:another_one()\n   self:some_method()\n   -- more code\nend\n\nfunction myclass.new()\n   local self = {}\n   setmetatable(self, { __index = MyClass })\n   return self\nend\n\nreturn myclass\n```\n\n* The class table and the class metatable should both be local. If containing\nmetamethods, the metatable may be declared as a top-level local, named\n`MyClass_mt`.\n\n\u003e **Rationale:** It’s easy to see in the code above that the functions with\n`MyClass` in their signature are methods. A deeper discussion of the\ndesign rationale for this is found [here](http://hisham.hm/2014/01/02/how-to-write-lua-modules-in-a-post-module-world/).\n\n* Use the method notation when invoking methods:\n\n```\n-- bad \nmy_object.my_method(my_object)\n-- good\nmy_object:my_method()\n```\n\n\u003e **Rationale:** This makes it explicit that the intent is to use the function as an OOP method.\n\n* Do not rely on the `__gc` metamethod to release resources other than memory.\nIf your object manage resources such as files, add a `close` method to their\nAPIs and do not auto-close via `__gc`. Auto-closing via `__gc` would entice\nusers of your module to not close resources as soon as possible. (Note that\nthe standard `io` library does not follow this recommendation, and users often\nforget that not closing files immediately can lead to \"too many open files\"\nerrors when the program runs for a while.)\n\n\u003e **Rationale:** The garbage collector performs automatic *memory* management,\ndealing with memory only. There is no guarantees as to when the garbage\ncollector will be invoked, and memory pressure does not correlate to pressure\non other resources. \n\n## File structure\n\n* Lua files should be named in all lowercase.\n\n* Lua files should be in a top-level `src` directory. The main library file\nshould be called `modulename.lua`.\n\n* Tests should be in a top-level `spec` directory. LuaRocks uses\n[Busted](http://olivinelabs.com/busted/) for testing.\n\n* Executables are in `src/bin` directory.\n\n## Static checking\n\nIt's best if code passes [luacheck](https://github.com/mpeterv/luacheck). If\nit does not with default settings, it should provide a `.luacheckrc` with\nsensible exceptions.\n\n* luacheck warnings of class 6xx refer to whitespace issues and can be\nignored. Do not send pull requests \"fixing\" trailing whitespaces.\n\n\u003e **Rationale:** Git is paranoid about trailing whitespace due to the\npatch-file email-based workflow inherited from the Linux kernel mailing list.\nWhen using the Git tool proper, exceeding whitespace makes no difference\nwhatsoever except for being highlighted by Git's coloring (for the aforementioned\nreasons). Git's pedantism about it has spread over the year to the syntax\nhighlighting of many text editors and now everyone says they hate trailing\nwhitespace without being really able to answer why (the actual cause being\nthat tools complain to them about it, for no good reason).\n\n* luacheck warnings of class 211, 212, 213 (unused variable, argument or loop\nvariable) should be ignored, if the unused variable was added explicitly: for\nexample, sometimes it is useful, for code understandability, to spell out what\nthe keys and values in a table are, even if you're only using one of them.\nAnother example is a function that needs to follow a given signature for API\nreasons (e.g. a callback that follows a given format) but doesn't use some of\nits arguments; it's better to spell out in the argument what the API the\nfunction implements is, instead of adding `_` variables.\n\n* luacheck warning 542 (empty if branch) can also be ignored, when a sequence\nof `if`/`elseif`/`else` blocks implements a \"switch/case\"-style list of cases,\nand one of the cases is meant to mean \"pass\". For example:\n\n```lua\nif warning \u003e= 600 and warning \u003c= 699 then\n   print(\"no whitespace warnings\")\nelseif warning == 542 then\n   -- pass\nelse\n   print(\"got a warning: \"..warning)\nend\n```\n\n\u003e **Rationale:** This avoids writing negated conditions in the final fallback\ncase, and it's easy to add another case to the construct without having to\nedit the fallback.\n\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fluarocks%2Flua-style-guide","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fluarocks%2Flua-style-guide","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fluarocks%2Flua-style-guide/lists"}