UI best practices With the low barrier to entry , writing mods has become very popular . While this has greatly benefited the WoW community , it does have a dark side . There are idiosyncrasies in both the Lua language and the World of Warcraft API that many authors overlook . This can lead to poorly written programs as measured by performance , memory usage , interference with other addons and the default UI , etc . The techniques gathering on this page will help help addon authors , experienced and otherwise , make the most out of WoW ' s environment safely and efficiently . General Scripting . These tips relate to Lua scripting in general . They are offered to help you write safer and more efficient code , and are applicable to non - WoW scripts as well . Use local variables . One stumbling block for Lua programmers coming from other languages is the fact that all variables are global unless specified otherwise . Many times , the use of global variables is necessary : saved variables are created via the global environment ; all API functions and UI frames are in the global namespace . However , globals come at a cost of both performance , and naming conflicts . Globals are inefficient to access compared to locals . Whenever a global is accessed , Lua has to call the internal equivalent of getfenv ( ) to figure out where to retrieve the global from . Local variables , on the other hand , are stored on a stack . In code where performance is important ( for instance an OnUpdate handler ) , it ' s often beneficial to create a local alias to a global function : Naming conflicts are sometimes a more pressing concern . The effects are usually much more noticeable . If two addons define print functions that work in slightly different ways , one of the addons isn ' t going to be too happy when it tries to use its own . Another problem can be taint . . . If you accidentally use the name of some variable that blizzard code uses ( e . g . arg1 ) , you can introduce taint . These problems are easily solved by declaring functions and variables local . There are other approaches as well , but this is by far the simplest . Hook functions safely . See also : You should do your best to write your addon in such a way that you don ' t need to hook functions . Even when it is necessary , most of the time hooksecurefunc is sufficient . However , there are occasional cases where " traditional " hooking must be used . When you do , remember to pass all parameters and return all results . Example : Even if the function only takes two parameters , you should always use the vararg ( . . . ) . This will help future - proof your hook . If parameters are added to the function , your addon will safely ignore them while still passing them along . There is actually a slight problem with the above example . If the number of return values from the function increases , your addon will likely cause erros . If you can call the original function as your last step , this is easy to deal with : If you need to do processing based on the return value , you ' ll need to create a table to store the results of the call : Make efficient use of conditionals . If you have a series of if conditionals , test the most efficient ones first . For example : There are exceptions to this rule , though . . . If one of the less efficient conditions is more likely to be the case , you should test it first . This way , instead of running both the fast test and the slow test most of the time , it only runs the slow test . E . g . : Short - Circuiting . Lua uses short - circuiting of conditionals . This means it only evaluates enough of the condition from left to right to know for certain whether it ' s true or false . In the case of " or " , the whole condition is known to be true as soon as one operand is true . For " and " , the whole condition is known to be false as soon as one operand is false . You can take advantage of this to add a bit of efficiency : Order of Operations . Lua , like many other programming languages , executes expressions from left to right starting from the innermost parenthesis to the outermost . This allows for un - nesting of IF blocks . Note : There are several programming languages that do not read left to right ( eg . Joy , Factor , J and K , etc . ) . Others - like Haskell - can be used both ways . There are even languages that are multi - dimensional . While many of these are mainly academic , they are not esoteric languages made to be weird , but rather based on recent theories and ideas in computer science . Lazy Coding . You can utilize the Short - Circuiting functionality to make sure a variable has a value before comparing it to a literal : You can also " cheat " if all you want to do is make sure a variable has a value other than nil or false : Minimize use of throw - away tables . Tables in Lua , being powerful instrument , can cause your addon to pollute memory with unnecessary garbage if you ' re not careful , as tables are one of value types that are not reused automatically . It is better not to use repeatedly generated throw - away tables unless they provide far easier to read solution , faster code or if your task is impossible to handle without them at all . In some cases you can minimize garbage generation when using those as explained in . API & XML . This section applies specifically to the World of Warcraft UI environment . Use local event handler parameters . With the introduction of WoW 2 . 0 , widget event handlers now provide local parameters . As mentioned in a previous section , accessing local values is more efficient than accessing globals . Here are a few examples of the old way and how they should be implemented now : Code directly in XML . Old New Note : Lua code must be inserted inside event handlers or it will never run . XML calling Lua function . Old XML Old Lua New XML New Lua Even Newer XML This has the advantage of resulting in a reference call , without an anonymous code block calling a global function . Lua only . Old New