Style is a crucial component of professionalism in software development. Clean code that follows stylistic conventions is easier to read, maintain, and share with colleagues. Programmers who code in good style are less likely to have silly bugs and will actually spend less time developing and debugging their code. Finally, good style in programs is a concern because for us, humans, style and aesthetics are a concern in everything we do.
Following stylistic conventions is easy, and, after a litter practice, becomes second nature. Occasionally, an especially independent-minded student resists all conventions, arguing, "But it works!" To this person, we can point out two things. First, a programmer's product is
not an executable program, but its source code. In the current environment, the life expectancy of a "working" program is just a few months, sometimes weeks. On the other hand, source code, updated periodically, can live for years; to be of any use, it must be readable to others. Second, bad or unconventional style is uncool. It immediately gives away an amateur, a kind of social misfit in the software developers' culture. As nerdy as this culture might be, it has its own sense of aesthetic pride.
In programming, style has a deeper meaning: it is that elusive quality which makes on person's code elegant and easy to follow than another person's convoluted and obscure although in line with all the superficial stylistic conventions. The mystery is not as wide open in writing code as in creative writing: there are many firm design principals, and "a person who thinks clearly" usually is able to code clearly. Still, some mystery remains. Here we discuss only the superficial stylistic conventions, leaving the deeper meaning alone.
Bit 0.At the top of each Lua file, put a comment that states the purpose of the file, its author, date of completion, and other pertinent info, such as a copyright message, special instructions on how to run the program, data files that your program reads or creates, and a history of revisions.
Bit 1.Place all dofile() functions at the top of your Lua file. Start with standard libraries/files (such as netlib) followed by your own files.
Bit 2.Separate different functions in a file with blank lines and separator comment lines. Split your code into "paragraphs" that represent meaningful steps or actions in your program by inserting blank lines, and, if necessary, comment lines
Bit 3.Place each statement on a separate line. Indent
Lua code is usually indented by a tab or 3 spaces in the body of the function or under if, else, switch, and for and while loops
Bit 4.Use spaces liberally. Do not cram things together.
There are no clear-cut rules on where to add spaces -- different people have different tasted. We use spaces on both sides of the assignment operator and other binary operators: Arithmetic, logical, relational. For example:
taxAmount=saleAmount*taxRate
less readable then
taxAmount = saleAmount * taxRate
