[GUI] VDAAO - Variable Duplicate Aversion And Organization

[Xeryxoz]

Introduction

I am sure everyone has experienced a duplicated variable once or twice in a map they were making. There are always many ways to regulate it, but nobody really does it. So in this tutorial I will be showing a few neat ways of how to avert

Our options...

The best one is using the first prefix(es) to account for a select system.

People don't use two same systems for the same goal, so the chance of overlapping is minimal, therefor if we put the first prefix to represent our system or it's name, the chances of duplication are very small. There is also the possibility of using your author's name or an unique part of it. That's something people can't overlap (Only if you type in a simple word in it like Chaos or Orc - this is where unique names are handy).

Examples :

EQsys_Uequip_Cast - Makes chances of the same named variable much lower.
Henn_Uequip_Cast - Nobody can copy an unique part of your name.

Slightly longer but it should be worth it. Because you labeled all your variables like this, it's easier to find them in the variable's tab. Not only that, but if you are not sure what variable corresponds to which system - this would be a much faster and safer way to understand.

You could also try combining...

EQsys_H_Uequip_Cast - Very low chance of duplication

And if that fails - the use of numbers in a thread is possible (now that would remove it completely).

294947 - This thread's number. I'll use it for the example bellow

T294947_Uequip_Cast - First letter represents Thread, as using the numbers first would cause some issues with the variables...

Anyways - using this method, duplicate variables would never happen, but organization would not be as good. You would also have to put the map on hive to get the thread as well...).

The only way someone could duplicate this last one is if they failed in copying and pasting their thread number (for some odd reason). When we also add into account that those two codes would have to be in the same map, I can proudly say that the chances of this happening are as low as science proving the existence of God....

Do note - changing variable and array names may cause triggers to stop working correctly, so make a backup copy just in case!

Final words

There are many more ways to avert duplication, but I think these should be the most efficient.
If you want to know more possibilities GPAG - GUI Proper Application Guide should be a reference.

 

[Daffa]

In GUI, this would have some use. Anyway, you might want a header or something to make this less messy.

There are several case where duplicates are needed. Yes, I know it's ridiculous as it sounds.
Take infamous Temp_Blabla with the Blabla changed into Point, Int and list goes on.

It's a good practice however, to have different variables whenever possible.

 

[Daffa]

Don't use that brownish something color. Use the red one instead.

 

[Xeryxoz]

In GUI, this would have some use. Anyway, you might want a header or something to make this less messy.

There are several case where duplicates are needed. Yes, I know it's ridiculous as it sounds.
Take infamous Temp_Blabla with the Blabla changed into Point, Int and list goes on.

It's a good practice however, to have different variables whenever possible.

Indeed, sometimes it may be good, but in most cases it can mess something up. Having a sure way of preventing duplication for most variables is good practice, just like you commented.

Don't use that brownish something color. Use the red one instead.

Kind of think the brownish one fits with the regular text color, but will do. Also, I've updated the Terrain Add-on, Would you care to look at the code and tell me what you think of the current version?

 

[IcemanBo]

I don't know if I find it good someone uses arbitary prefixes. It should be system related, and for example usage of thread numbers doesn't make any sense.
The variable should be associated with a spell, or system, so a useful prefix name is asked for. And if a good prefix name is chosen, then it's most likely enougb safety for most cases. Sorry, not sure this this is a good tequnique to use.

 

[PurgeandFire]

I have to agree with IcemanBo, I feel like this is covered well under GPAG. In general: (1) be consistent (use the same prefix system throughout your map), and (2) make sure it makes sense for the trigger. Choosing a random number or prefix is just going to be confusing.

Thanks for the contribution. Sadly, I think I'm going to graveyard this, sorry.

 

[Xeryxoz]

I have to agree with IcemanBo, I feel like this is covered well under GPAG. In general: (1) be consistent (use the same prefix system throughout your map), and (2) make sure it makes sense for the trigger. Choosing a random number or prefix is just going to be confusing.

Thanks for the contribution. Sadly, I think I'm going to the graveyard this, sorry.

No problem ^^ I mean, this was a one-shot idea which was aimed to cause better sorting in the variables and the ability to quickly identify which system what variable is connected to ^^ (To think that I made this a year ago..)