[Trigger] Variable Naming Standards

[Furry Nova]

Does the GUI Trigger Editor have a recommended variable naming standard? I mostly script in JavaScript and Node.js. They use camel case (exampleVariable) for normal variables, pascal case for classes (ExampleClass) and all uppercase with underscore for constants (EXAMPLE_CONSTANT).

I've been browsing this forum a bit and found one style they use is pascal with underscore (VariableType_VariableName). Is this preferred?

 

[Pyrogasm]

camelCase or underscored are pretty much the only 'standards'. Pick something that works for you, though I recommend constants and stuff to be in ALL_CAPS just so it's obvious.

 

[IcemanBo]

Usually PascalCase IsUsedInGUI ToWriteLikeThis AndStartEachWord WithCapitcalLetter.


For all resource related variables we add a unique prefix in capital letters and connected with underscore:

FIREBALL_Point
FIREBALL_Unit
FIREBALL_Int
...


For constants by your spell/system that should be never be changed one can write all with capital letters, which implies a constant:

FIREBALL_OFFSET
FIREBALL_STATE_LAUNCH
FIREBALL_STATE_MOVE
FIREBALL_STATE_HIT

==

That's pretty much the standards. But in GUI there is no hardcore enforcement or so, because the users don't really writtenly use any API like in JASS.
So if you are much into camelCase for normal vaiables, you probably might also go with it instead of the PascalCase.

 

[Furry Nova]

Thanks for that. I can see it really helps group code and reduce clashes with other resources.

Is there a standard with temp variables? Example on another post I saw a Real variable named Real. I'm wondering which would be preferred, maybe like TempReal or TEMP_Real? But TEMP_Real technically not an input resource so I'm presuming TempReal or Real?

 

[IcemanBo]

Temp variables suck a bit in GUI, because they're always globals.

In JASS, you choose short and descriptive names:

local real angle
local integer counter
local player owner
...

In GUI, you can't really give good names for temp variables, because they are used globaly, and should be descriptive for potentialy all triggers.
So, yes the "solution" is to give generic names like "Real" "Int" "Player" and so on. Many people write "TempInt" or so, yes, like you said, but personaly I don't do this anymore.
I think for me it's clear that "Point" "Int" "Real" "String" etc are my temp variables in GUI. When my system uses temp variables, then "FIREBALL_Int", "FIREBALL_Int2" etc.
Because when I'm not using temp variables, then I anyways choose not genric names, but choose specific names, like:
"Unit" -> generic name -> Temp variable
"Caster[]", "Target[]" -> specific name -> not temp variables

 

[KILLCIDE]

Whenever I make a variable in GUI, I always do it in PascalCase. Personally, camelCase is harder for me to read in GUI.

In terms of variables for a specific spell / system (members), I make the prefix as descriptive as I can without it being too long. For example, if a spell was called Blizzard, I would do something like: Blizz_Caster and Blizz_AbilityLvl. You will see a lot of resources in the Spell Section just use the spell initials like BL for Blizzard. I tend to avoid that because it's way too generic and can definitely cause issues if there is another resource using BL as their prefix. The chances of another resource having Blizz as another prefix are much slimmer.

For temporary variables in a specific spell / system, I just go on the safer side and do: Blizz_TempInt and Blizz_TempLoc. If you are making your map, and you know what you are doing, you can just leave things as TempLoc or TempInt. However, I am aware that there are a few resources in the spell section still using generic names like TempInt and TempLoc, so you will just need to watch out for GUI spells and systems that have these.

 

[Furry Nova]

I'm not sure if this is correct. I think the only risk with global temp variables are wait delays. If resource A has a wait delay action after setting a temp variable and then resource B modifies that temp variable for it's use that causes problems with resource A after the delay that uses it. I don't know if for loops can cause this.

Sorry if I'm sounding off topic this post. All your information and advice has been ready helpful.

 

[KILLCIDE]

Waits are not the only way global variables can be conflicting. Triggers can simultaneously run with another trigger. For example:

• For each (Integer LoopInt) from 1 to SomeOtherInteger, do (Actions)
  • Loop - Actions
    • Set TempInt = 1
    • Unit - Kill SomeUnit
    • If (All Conditions are True) then do (Then Actions) else do (Else Actions)
      • If - Conditions
        • TempInt Equal to 1
      • Then - Actions
        • Custom script: call BJDebugMsg("1")
      • Else - Actions
        • Custom script: call BJDebugMsg("2")

• Unit Dies Trigger
  • Events
    • Unit - A unit Dies
  • Conditions
  • Actions
    • Set TempInt = 2

You set a global integer variable to 1, and then kill a unit immediately after. That loop will pause because you triggered another event: A unit Dies. The Unit Dies Trigger will run, set the global integer variable to 2, and then the loop will go back to what it was doing. With this in mind, the message you will see display is 2, and not 1. You can imagine what kind of issues this can create.

 

[IcemanBo]

A good system should never influence anything not-system related. Never! If possible...
So when the user has created a "TempInt" variable and uses it by himself, then now the imported system also works with "TempInt", then it's very bad.
"TempInt" will have new values, that were never intended by the user, and that's just poor coding.

[...] was writing the other example, but killcide was faster.