Help:Lua/Lua best practice

As any "best practice", this Lua best practice is heavily influenced by any individual contributors impression of what should be good practice. Use whatever you believe is important on your specific project, but do also know that these rules have been found to work!

The examples in the following are for Lua, but it should be easy to reformulate for JavaScript, PHP, and Python. The reason for giving examples for Lua is that modules for this language are used a lot, often by non-programmers that does not see the consequence of their choices.

As a general advice it can be a great help to at least import the content into a proper programming environment and check it there for obvious flaws and errors. Several free options exist, among them Eclipse, TextMate, and Visual Studio Code just to mention a few.

Formatting

 * Limit line length
 * Lines should be limited to a reasonable length, typically 80 characters. The reason is that long lines are hard to read, but more import, long lines tend to contain several intermingled concepts and editing them will tend to create new bugs.

Comments

 * Why-form of comments
 * Comments are not for you who code some algorithm, they are for the one who reads your code. In the code path there should be answers to the how-questions, and in the comments there should be answers to the why-questions. Do not fall in the trap of replicating what you do in the code path in the comments!


 * Refactor on comments
 * When the code has become to complex, it is common to start explaining the code for yourself. If you need your own comments, then something has gotten to involved and you should refactor the code.

Code

 * Use patterns
 * A lot of work has gone into identifying common software design patterns, and developing good general solutions to those patterns. If you suspect you are attempting to do something that has a common pattern then do a search and check out how to implement the pattern. Still, know that patterns for languages with closures can be very different from those without closures.


 * Complexity
 * There are usually several execute paths through a given code, and this makes the code difficult to understand. The more code paths the more difficult the code become. This can be measured as cyclomatic complexity, and is a count of paths by counting branch points.

Reading

 * Kerievsky, Joshua; Refactoring to Patterns
 * Boswell, Dustin; Foucher, Trevor; The Art of Readable Code