|
|
|
1.) Basic mistakes - In most places, not all, that I look, I see codes barged with: halt, excessive slashes (/), excessive Goto's and NO error checking. People need to understand these three basic flaws of scripting.
a.) Halt - The 'halt' command use to be used in place of a 'return' command. This command basically halted the rest of the script from processing. The problem with halt is, if you used it in, say, an event procedure, every other script was halted from evaluating an event in it's own way. You don't want to interfere with the way other scripts operate on a user's mIRC client, most likely you just want to halt your events from taking place. Thanks to later versions of mIRC, the 'return' command was implemented and can now end the rest of a script from processing without halting other scripts or functions within your script.
b.) Excessive Slashes (/) - Slashes are still used everywhere where they are unneeded. For example, you don't need this:
alias echo3 {
/echo 1
/echo 2
/echo 3
}
You would want to remove the slashes from this code, and make this the end result:
alias echo3 {
echo 1
echo 2
echo 3
}
Not only does this save space (not much, but some for those of you who create large script files), it also improves quality and the way the code looks. Believe it or not, scripts are like cars: The way the engine works/looks is very appealing to someone who's using it.
c.) Excessive Goto's - Users use 'goto' statements MOSTLY to exit processing. You don't really need this anymore, thanks to the 'return' command (see item 'a' for information on the 'return' statement). Goto's can be important with cutting down file size, in most cases. For instance, instead of doing:
on *:DIALOG:mydialog:*:*: {
if ($devent == init) {
echo -s INIT
}
if ($devent == sclick) {
$iif($did == 1, echo -s Button 1)
$iif($did == 2, echo -s Button 2)
}
}
You could do this:
on *:DIALOG:mydialog:*:*: {
goto $did
:1
echo -s button 1 | return
:2
echo -s button 2 | return
:0
echo -s INIT
}
d.) No Error-Checking - I see this way too often. I explain it a bit in the 'Testing' section, but here is a bit of information. Error checking is needed almost everywhere in a script/addon. For instance, if you have made an identifier for users that will get the $duration of the seconds they return, you would use this alias:
alias cdur return $duration($1)Use: $cdur(S) Where S is the amount of seconds to get the duration of.
Now, what happens if the user just does: $cdur()? You will get an 'insufficient parameters' error of some sort. This means that the user did not specify the correct number of parameters for this identifier. The best thing to do would be to return an error to the user, without mIRC getting involved and halting your processing. Try doing this:
alias cdur $iif($1 != $null, return $duration($1), echo � $+ $colour(info) $+ You did not specify the amount of seconds to get the duration for!)This will basically check to make sure that $1 is not $null and if not, return the duration else return the error. Now, what if the user puts a letter in place of the where you want a number? Well, you won't get an error, but suppose you want to make sure that what is there is a number ONLY. Simply put this:
alias cdur $iif(($1 != $null) && ($1 isnum), return $duration($1), echo � $+ $colour(info) $+ You did not specify the amount of seconds to get the duration for!)Basically, isnum will make sure that $1 is a number, indeed. (Note: I just stuck this in here to be more in depth on what I was trying to say. Error checking is important in order to make the end-user's use of the addon exactly how you intended it to be used.)
2.) Dialogs - Almost everything should be configured in every fashion or form through dialogs. If they can be easily accessed through popups (much easier than opening a dialog), you should consider combining your quick options into 1 large dialog option window. An example would be an MP3 Player. I see all of these people creating MP3 Players that are menu based. *EH* *EH*! This is a very bad choice. And I *stress* *very* :-) At least, people want dialog configuration and as much ease as an mIRC built Player can offer. mIRC Players can have fully skinnable windows with little or no effort (depending on your skill of scripting).
3.) Repition - I cannot stress this one enough. Repetative coding is very annoying, and sluggish. In fact, a bigger script file is much slower than a smaller one. You don't want to use $readini functions over and over when you don't happen. You could *simply* do this:
alias GetIni readini <IniFile.ini> $1 $2. ;At this line, you would replace <IniFile.ini> with the name of your ini file. As you may ;have noticed, I referred to this as *simple*, as in: error-checking is not evident. This ;is because most advanced scripters know how to error check. Just make sure that $1 & $2 ;have values ( $iif() )Use: $GetIni(<S>,<I>) Where S is the section to read and I is the item value to retrieve from section S.
More repetition involves users opening/closing dialogs through Menus/Aliases/Dialogs, etc. You don't have to have a: dialog -x DialogName every single time. Your best bet would be to use one solid code for ALL dialogs:
alias cdialog dialog -x $1Use: /cdialog DialogName Where DialogName is the dialog you wish to close. For example: /cdialog MyDialog. This eliminates a lot of /dialog -x procedures that you do not need.
4.) Colors - Oh my goodness, colors. People need to understand that not everyone has the same color configuration. On a similar note, not everyone uses the same font or point size either. You need to allow customization of your addon if it does something on an mIRC window. Understand that users may be using a black background, so don't use any color codes involving black as the foreground without specifying a background that will allow it to be seen. Your best bet would be to use mIRC's built-in actions for displaying status and then using that to alert the users of things. The basic function for echoing to a status screen would be:
/echo -s � $+ $colour(info) $+ Your alert here.If you wanted to eliminate repetition for this as well and add functionality, you could do:
alias myecho echo $1 � $+ $colour(info) $+ $2-Use: /myecho <F> <E> Where <F> is the flag for where you want the info echoed (Example: /myecho -s Hey! This is my echo <-- This would echo to the status screen in the mIRC INFO color). <E> is what you want to be echoed to a screen.
5.) Testing - Testing determines, pretty much, whether or not your addon is a hit or not. Will people like the way it looks? Do the dialogs look crummy? Are the menus and items arranged in a nice fashion? Is it appealing to close friends? The best way to get testing done is by sending it to friends that you may have on mIRC. You can get information from your friends and feedback. You want to vigorously test your addons/scripts to find all errors and bugs and pretty much make them bugfree, although this is impossible in most cases, limited bugs/errors are preferred. Simple tests involve performing operations that your addon/script may or may not have been made for. For example: If your dialog requires a user to type a new nickname in, make sure that you check to make sure that the nickname doesn't involve any commas, spaces, etc. These are commonly made errors that users may or may not have intently performed, but it is your job as the author to make sure that their mistake does not cause any errors within your addon/script.
Most people are going to say: "Man, I knew all of this stupid information before." Perhaps, perhaps. If it was a waste of your time, I'm very sorry. It is intended to be simple information. I just wanted to let users know a few 'quirks' that are done in most scripts/addons that are viewed thus lately. Any comments are welcome. :-)
|
|
|