tComboPoints optimization and feedback
Good afternoon everyone. I finally feel comfortable with the ability of my addon to be bug free and work exactly as intended. I have published it for others to use, and am now looking for feedback on my coding for future addon endeavors.
This addon is a simple combo point tracker with support for various rogue talents as well as a subtlety specific function which generates combo points when you successfully auto attack a number of times. The code may be found here: https://pastebin.com/MDRmMJeg I welcome all criticism of styling and coding efforts. Please feel free to include areas I could optimize memory/cpu usage or I have strangely styled something. Thank you. |
These calls will not work on a non-english clients:
Lua Code:
You gonna have to use spellIDs, these are the the proper arguments for the 3 event type you need: Lua Code:
|
Thank you, good point.
I've updated it to: Lua Code:
|
I would advice you to start using descriptive variable names, like the ones Resike suggested, as they explain exactly what you are checking for, and it will help you in the long term, as well as anyone evaluating your code.
|
p3lim,
Thank you for your feedback. Huge fan of your addons and your code. When I saw the difference in readability between arg2 and spellID or what not I saw the importance of naming variables more descriptively. One possible problem with this is that the 12th argument for a swing_damage event is a an amount of damage or a string of miss, block, parry, dodge, etc, whereas the 12th argument for spell_damage is a spellID. To assuage this problem, I could have the first 4 arguments set as they are always the same, and then perform an if check on the 2nd argument to determine type of CLEU event. At that point I could assign variables that would be more accurately and descriptively named, but I would be utilizing extra CPU cycles to perform the check, overwrite the 2nd and 4th arguments unnecessarily and also have extra variables taking up (albeit minuscule) amounts of memory. Outside of the CLEU variables, are shorthand such as STF for shadowtechniquesframe acceptable? Or do authors generally give longer names? |
You can name them whatever you want. If you will remember in a year what STF is for, then go ahead and name it that. The purpose for descriptive variable names is so that you will remember when you come back later to maintain your code. It also makes it easier for anyone else reading your code. You don't *have* to do it, it's just nice.
For args that can be different types of values... Aren't you going to be doing different things based on what CLEU event it is anyway? |
Quote:
Lua Code:
Any code that is general and applicable to every event can be written directly in the event handler. In the case of processing combat events, you can apply the same principle. In terms of optimisation, there are a couple of things you can do, such as upvalueing the sub table in your color picker instead of doing the table lookup 3 times (one for each color value), but it will hardly make any difference with such a tiny code snippet. |
Munk,
Thank you for the feedback. I've seen others use Lua Code:
And I get the concept of how it works, but I don't truly understand the syntax. My understanding is this: we see if the event is a table key of our function table with Lua Code:
Later in the code you name the function like: Lua Code:
but wouldn't this create a global function as there's no local before the function? Or is it still localized because that function is bound to (in this case) the STF frame from the initial SetScript? Additionally, I don't understand how you would upvalue a table value. I understand that an upvalue look up is faster than a table look up, especially three table look ups, I just don't fully grasp how you would do it. Thank you for everyone's comments and feedback. It has been very helpful. |
With the API "CreateFrame", what that really does is create a table and inject it with methods (in essence).
When you create a function "frame:PLAYER_LOGIN" you are basically assigning that to the table "frame". Lua Code:
Lua Code:
So in SetScript in that example, you're calling the function by its table key in the current table (or frame rather), which in the context of SetScript is "self". You could just as well (in the SetScript block) call it by "frame[event]" (just in case the "self" variable confuses you). And the value for that key would be the function. It's never global, but you can access it globally if the frame itself is global (either by variable or name, the 2nd argument in CreateFrame), by using the key (in this case PLAYER_LOGIN or any other event). The reason you check for "self[event]" is to make sure you don't get errors when the function doesn't exist in the table. |
All times are GMT -6. The time now is 07:25 PM. |
vBulletin © 2024, Jelsoft Enterprises Ltd
© 2004 - 2022 MMOUI