Other scriptors are welcome to mention some other similar scripting basics that I've not mentioned here.
Something else that too many scriptors bypassed as they learned how to code is the aspect of getting their script to 'play nice with others'. In most coding environments, it doesn't matter how your code behaves internally, so your choice of variable and procedure names doesn't matter much at all. However in mIRC, your script needs to share global variables and hashtables with other scripts, and if your script can call or be called by scripts written by other people, it could need to share things like binary variables or regex 'names'. You want to try avoiding trampling all over another script's settings or using labels which makes it more likely that another script tramples all over yours. Some related suggestions:
1. Don't create global variables using a single letter like %a, or as a simple word like %settings or %time without expecting another poorly written script doing the same, causing unpredictable results for both scripts.
If your variables don't need to be global, have them be local instead, where you're free to name them whatever you wish, and they're automatically wiped out when your script finishes. For global variables, it's better to have longer names that are less likely to have cross-script interference. One possibility is to include your script's name when naming the global variable, like %myscriptname.time
2. From observation, it seems that 'foo' is a label that's commonly used in scripts as the name of a &binvar or regex-name, in situations where nobody cares if the contents get destroyed by another script after their script is finished.
When a script uses $regml(1), it's the result from one of the regex identifiers, or even from an ON EVENT which uses a regex pattern as a match string. If you don't want your results wiped out by another script, then use a different optional name in your use of the regex identifiers and then use $regml(your-name,1) instead of $regml(1).
When your script creates a &binvar or a local %variable name for the 1st time, always assume that another script (or even a prior call of your same script) has left behind content in that &binvar name, or that there's a global variable existing as the same name as the local variable name you want to use.
3. Same goes with hashtables. You can't prevent another script from naming a hashtable anything it wants to use, so pick a name that's not likely to be used by other scripts.
4. If making a script for others to use, don't assume they use the same screen colors you do. While the default install of mIRC has a white background, many users prefer a black or gray background. Some colors which can be easily read against a white background are very hard to read against the color black. And vice-versa. For example, "/echo 8 -a test" shows text in yellow that's easily read against a black background, but extremely difficult to see against a white background. On the other hand "/echo 2 -a test" makes the text be blue, which can easily be seen against the default white background, but is extremely hard to see against a black background.
One solution can be to check the current background color, then behave differently depending on the settings.
Another solution is to provide your own background color along with your own colorized text, which lets you ensure visible contrast. Well, assuming the user hasn't defined those color indexes in a way which no longer has the expected contrast, in which case that problem could be avoided by using color indexes in the range 16-98 which can't be edited.
Another solution is to assume that the user's color settings have defined certain events with good contrast from the background and which are different than other settings. For example, you could do like:
/echo -ac ctcp test1
/echo -ac notice test2
/echo -ac info test3
5. Don't assume your script will always have a chance to clean up after itself. If your script uses global variables which have been created using the -e switch, those variables were created with an 'unset' flag that deletes those variables 2 billion seconds into the future. While your script isn't likely to have the 68 years of uptime needed to unset that variable, it's possible for that variable to exist the next time you restart mIRC itself. While temporary variables created using the -uN or -e switches are cleared from vars.ini during exit, they do get saved to disk during normal use of mIRC. So, if mIRC isn't able to properly exit due to a crash or a power failure, those temporary variables can exist in vars.ini the next time mIRC start, only now the temporary variables exist permanently without any flag set for future unset'ing. To defend against this, if your script creates any temporary variables, it might be a good idea to have an ON START event handler which deletes them.
