Which style you choose is up to you, as long as you don't pick the last one, because that is very bad programming practice, and is basically an invitation to parsing errors.
Apart from that, there are certain rules you must take into account:
if (condition) command | command
--> does not work as intended.
if (condition) { command | command }
--> works as intended
For single command statements such as:
if (condition) command
if condition { command }
if (condition) { command }
it doesn't matter what you pick, pick whichever one you think looks good for you, because as far as speed is concerned, these aren't the speed intense parts where you'll be able to save some processing time. Real speed gains will come from the way you code something, which algorithms you use, not if you use brackets or not. Only in tens of thousands of iterations will these parse speed differences become apparent, but the difference will still be near neglectible.
So, to conclude, pick whichever one you wish, but make sure that mIRC's parser can always know the boundary between where the condition stops, and the command starts.
In other words NOT like this:
if $1- == blah echo -a lol
--> Hard for the parser to know if the "echo" part is still part of the == check, or if it's the beginning of a command. Compared with the following, where mIRC can perfectly know where the condition ends, and the command begins:
if ($1- == blah) echo -a lol
or
if $1- == blah { echo -a lol }
or
if ($1- == blah) { echo -a lol }
If you're really interested to see the speed differences (just for fun), then do some benches, or look around with the
Search feature, although the speeds of parsing might vary from mIRC version to version.
To conclude, what style you choose shouldn't be based on speed, but on what looks good for you, and what makes sure that mIRC will parse it in the way that you intended it.
I used to prefer the if condition { command } way, but now I've changed to if (condition) command because I think it looks neater. My code hasn't gotten slower or faster because of this choice though
