I dunno about Lua but the general rules in programming are:

Make simple things simple. Create abstractions to handle complexity.

Make your software modular so you can change the parts of the code later without breaking everything.

Avoid hardcoded constants and magic numbers.

Avoid global state.

Especially that in Lua. local is your new best friend. Use it like a mantra. Only use global variables when your really need them. I still am annoyed by Lua that its default scope is global instead of local. That's a big design flaw IMO, it should have been the other way around. But whatever.

Using local as often as possible will avoid weird naming collision bugs when you work with multiple Lua files.

I sometimes use a tool called “luacheck” to hunt down unneccssary global variables and other oddities in Lua code.

Then the other soft rule I have is just “get your indentations right”. Sometimes just fixing the indentaions can do wonders to a messy code.

But I admit that current HW scripts are not always good at my own tips.

In missions and multiplayer scripts, I try to keep the writing of mission panel consistent across scripts. Title is always the mission or style name, caption is a categorization or witty tagline. The rest is description.
Try to keep the current mission or gameplay rules visible and true at all times, so it can be reviewed later by the player. For complex scripts, that's not always possible yet, however.
I tried more or less to follow this in all missions and scripts, check out the Alpha for examples.
For simple scripts I also tend to prefer using Goals over ShowMission (see Highlander in 2nd Alpha), because Goals doesn't overwrite the description of other game modifiers.

Apart from that, just general programmig rules apply like everywhere else (e.g. https://en.wikipedia.org/wiki/Don%27t_repeat_yourself and some other rules, just search the WWW). Lua isn't really special.

At one point I wanted to write down some kind of Lua script quality guideline to include stuff like the mission panel but I haven't done so yet.

btw, the process of cleaning/simplifying code without the change in functionality is called "refactoring".

Lyberta, Wuzzy, and KoBeWi
Thanks for teaching me !(OwO )_/ ||greyboard||
I really thankful for these, homina homina homina

@Lyberta Quotes: "Make simple things simple. Create abstractions to handle complexity."
"Create abstractions to handle complexity"? What does that mean?
Complexity can be handled by using abstract method? Hmmm...
And anyway, those general informations are helpful, avoiding magic stuff is sure right!

@Wuzzy Quotes: "local is your new best friend" ; "Using local as often as possible will avoid weird naming collision bugs when you work with multiple Lua files."
Ah, I'm quite related to this long ago (in galaxy far far away?)
And that's right! local are my best friend! (I think too much of locals in mine x))
"luacheck"? Is it kind of IDE? Or stuff that I didn't know? (Hoping it was a Notepad++ plugins xD)
'Then the other soft rule I have is just “get your indentations right”'
Yeah, I have my style of indentation, using tabs for the most, it's good right?
And I feel pretty good at indentations stuff IMO, idk if it's in another perspective (go optimist! weee!)
"check out the Alpha for examples." ah, this one kinda interesting (rly), I do so if I can get hand on those, real quick
"Lua isn't really special." uhm! Please tell me about it, I'm beginner in these :]

@KoBeWi Quotes: 'btw, the process of cleaning/simplifying code without the change in functionality is called "refactoring".' Yay! It's great to know :O! Shoulda checkidup! *writing awkwardly onto Google*

-------------------- What, the, heck, is, this...

And for more sillyness overhype by me:
Thanks guys! I shall reward you all with bunch of text (^above)!
^^

EDIT: Hey! I have never tell ya enough! I'm human, therefore nothin' shall be enough :]] [/]

I'd also suggest reading the engine.

That way you know what will happen if you twiddle something in some way.