Just a side note: Lua is not an acronym and therefore shouldn't use all capital letters.

Readability vs Efficiency

Some people say efficiency is more important, others will say readability is more important. I say they're both right. If you asked a computer, it wouldn't care what your code looks like. Just give it something to compute and it will do the best it can every single time. So why worry about such details if the readability of your code doesn't matter? Well, because it does. A lot.

Like I said, the machine doesn't care what your code looks like. You could use a numeric for loop that prints 1-100,000, or you could have a one-hundred thousand line program that manually prints each individual number on a new line. The machine doesn't care, but us people do! An example like that really shows the difference, and the importance, of readable code. Could you imagine having a section of your program that looks like this:

print(1)
print(2)
print(3)
...
...
... -- 99,997 lines of code later
print(100000) 

That would be madness! Who even cares if it's more efficient at that point. Programmers often shave down some degree of efficiency in order to maintain code that they can actually read and understand.

But, Wait!

Don't get the wrong idea, I'm not telling you to neglect efficiency altogether just to keep your code nice and pretty (even though it would be wonderful if we could). There are times when even programmers can no longer abstract things to make more sense to us, so we just accept the harsh reality that sometimes the best solutions can look messy. This would typically be in an extreme circumstance where the performance penalty far outweighs how readable your code is. Or perhaps you're trying to optimize your code and you're looking around for things that you could make more efficient.

So, When is Optimizing Necessary?

Low-level operations, or even operations that the hardware itself is designed to do, is a lot different from our human "abstractions". If you're a computer hardware engineer, where you deal with incredibly delicate procedures that you almost never think about ever again once it's out of the way, you're going to find that making even the slightest mistake can be detrimental to performance. Situations like these require fundamental instructions that even humans can no longer abstract or manipulate to make it easier for us to read. This is why we have software in the first place, to interact with the ugly (but efficient) hardware that we want no part of.

This is one reason why people usually say that efficient code is harder to read, or even generally messier than code written to be understood by a human, because it's less abstract. Now is this true for all situations? No. You can write readable code, and efficient code. But trying to make something more efficient that's not causing any problems, or that's not prone to error or hog resources, should not be focused on.

Summary

Just be careful. Write code so you can understand it, but also be mindful of what you're doing. It's fun to know things, but sometimes it's also dangerous and distracting.

Programs must be written for people to read, and only incidentally for machines to execute

As a programmer, it is your job to write code. However, a much larger part of your job is reading code.

The computer doesn't care how 'poorly written' your code is; it doesn't care how ugly or pretty or long or short. The person who does care is you -- the person who, in one hour or five days or three months, is going to realize you made a mistake and need to change something.

Cleaner code is better for the humans involved in programming. That means it's

• faster to read and understand
• faster to fix
• less likely to have bugs / mistakes
• easier to replace / rewrite

The goal is make it easy to write correct code and hard to write incorrect code.

Once you're good at it, it's also faster to code. You get a better sense of what's important, and you'll make fewer mistakes, because you know how to structure code in a way that makes it easy to do it correctly.

Faster code

Most of these style suggestions don't make your code faster. In fact, they can make it a few percent slower. It's a cost-benefit tradeoff that you have to make. In 99% of situations, the benefit of having human readable code outweighs a 1% performance penalty.

However, better code can make for faster code.

• For optimized languages, the compiler can do more (not relevant to Lua in ROBLOX)
• You can more easily profile and replace slow components -- which makes it easier to make a slow program faster
• You use abstractions that let you identify what kinds of algorithms would best suit your problems

What you have to do

Write for humans. In particular, write for other humans. You won't remember why or how something works if you revisit it after a few weeks.

With that in mind:

• use good, descriptive names for things
• don't repeat yourself -- use functions and (esp. generic for loops) as much as possible
  • if something has to be done twice, you probably want it in a function.
  • if something can be done easily in a general way, you can do it in that general way. You'll probably need it later.
• use comments to describe anything not obvious.
  • if you need comments to explain something, that might be a sign you can do it in a simpler way
• follow "best practices" for your language/project.
  • tab your code! Show blocks with indentations!
  • use locals a lot. declare variables as late as possible.
    • avoid globals
• be consistent with everything:
  • names
  • spacing rules
  • quoting styles, comma styles
  • indentation
  • bracket / keyword placement