Es posible dividir las líneas de código compartidas en partes individuales, realizar llamadas dependiendo de los eventos realizados por el usuario y preveer los posibles conflictos o terminaciones erróneas de las llamadas realizadas.

mIRC nos ofrece amplios recursos para ello, que no es materia de éste artículo explicar, ya que lo alargaríamos demasiado y no es nuestro objetivo dar clases de programación. Se supone que quien scriptea seriamente esos recursos ya sabe usarlos.

Con la optimización se adelanta y se aclaran una serie de errores que pueden darse habitualmente durante la ejecución de un código, como son:
-la optimización es una forma eficaz para la detección de bugs
-algunas técnicas de optimización harán que tu código sea más portable
-tú obtienes más control sobre tu código
-la optimización hará que tu código sea duro, consistente, estable y firme.

Existen diversas técnicas, todas ellas legítimas y que entran más en el terreno de los gustos personales y de la manera de cada uno que del propio resultado final. Mientras el punto de conclusión sea parecido, no debe importar tanto qué camino o caminos tomamos para ello.

Sin embargo, y sin que sirva como modelo preferencial, para una visión didáctica del tema pasaré a relatar por encima el propio estilo que sigo personalmente.

Primeramente, no puedes dividir tu código y hacerlo más óptimo mientras no tengas claro qué funciones persisten en él y cuál es su cometido. No puedes tratar de la misma forma todo ya que tú no tienes potestad sobre el motor de ejecución (hay que recordar que estás programando para un programa, valga la redundancia, no el programa en sí. De ahí que se llame scripting).
Yo divido las partes del mIRC y todo lo que influye éste en varios campos*1: primeramente, el mIRC no como programa, sino como generador y soporte, lo que se denomina mIRC engineered scripting (motor de scripting del mIRC).
Ha continuación, y sobre ello, se ensambla, lo más perfectamente posible, el código principal. Es el código con el cual, sin él, el script no sería script, no funcionaría o, en caso de alterarse, podría funcionar erróneamente*2. Es lo que denomino "kernel" del script.

En las primeras actualizaciones el kernel era necesario para actualizar el script. Después ya no era imprescindible ya que se le puede añadir soporte para actualización. El motivo de haber retartado ésa actualización era la ligereza del código final, y encontrar un punto medio llevó su tiempo. Hay que tener en cuenta que el kernel es capaz de trabajar, teóricamente, con cualquier addon medianamente bien programado.

Tras el kernel se encuentran unos archivos de uso de cara al programador, es lo que se denomina "modules support & interprety"*3. En ellos englobaríamos los ini, módulos, etc.

Encima de todos ellos esta el integrity check, que es la defininición para conjuntar tanto los errores que pueda captura el mIRC como programa de ejecución, o el propio script. Es conveniente tener bien claro éste concepto.

Como parte final y de nivel más alto se encuentra lo que denomino "scans and external reads", son archivos de usuario y engloba todo lo que el usuario puede añadir y hacer. Como se puede ver, está en el nivel más alejado ya que no lo considero imprescindible, pues su uso cae en manos del propietario del script. Por poner un ejemplo extremista: yo no puedo preveer que él introduzca código de un troyano.

Repito que ése es un modelo que me sirve a mí, y está expuesto como materia didáctica. Soy consciente de que muchos programadores están desarrollando sus propios modelos (otros los han desarrollado ya) que son tan válidos como éste, o más.