Simple question

Miscellaneous Forums/General Discussion/Simple question

okay, assume you had a set of functions whose purpose was the following

A) a function that adds a variable to an object and sets it to a value specified ONLY if the variable doesn't already exist.

B) a function that modifies a variable in an object if it already exists, otherwise if it does not already exist, it does nothing.

C) a function that modifies a variable if it already exists, or creates it and sets it to the value specified if it does not already exist.


What I need are the best names for these 3 types of functions. I want names that are short, but really evocative of what they do, as there will be a number of each type of functions to work on different data types and such.

My initial thoughts are

A) AddVar
B) SetVar or ModVar (for modify variable)
C) SOAVar or MOAVar (for "Set or Add var", or "Modifiy or Add var")

I suppose these seems like a stupid question, but I just want the names to be really clear and yet short, as they will be used all over in my behavior system module, and since I'm hoping others will find it useful, I want to make it as clear and as understandable (and easy to read) as possible.

I'm wondering if "SetVar" is a bad choice - would most of you assume that "SetVar" would add the variable specified if it didn't already exist? Imagine the following call

SomeObject.SetVar( "TestVariable", "test value" )

What this really does is set the variable named "TestVariable" to the string "test value" if and only if "TestVariable" already exists in SomeObject. Is this what you would assume, or does it seem like with a name of "SetVar" it should create the variable if it doesn't already exist? That's why I was thinking "ModVar" might be more descriptive, as usually you can only Modify that which already exists.

Ah, the joys of designing code meant to be read by others :P.

How about a function called setvar which takes a parm depending on what you want to do.
e.g. Function object_addvar(flag=0)
(or whatever depending on your normal naming convention. You migh use AddVar_to_object etc).
Then select/case on the flag and call seperate functions/methods from within your setvar function.

I thought about that, but was thinking that might make it harder to read the code, as you'd always have to look at the parameter to see what it was really doing. Of course, that's not so bad, but the biggest drawback to that method is that, I imagine it'll make the function calls quite a bit longer, which
might get annoying since all variable updates are going to be
going through that function.

Also, I don't know if it would amount to much but the additional overhead of the select/case might make a small impact as these functions will undoubtedly be called many many times per update.

Hmm, thanks for the response though. I will ponder that some more. One nice thing about that method is the benefit of being able to simply change a global flag variable to for instance, disallow the "adding" of variables after some point in the game. I.e, you could, for whatever reason necessary during testing, disable the ability to add new variables by changing the ADD_VARIABLE global flag to say "MODIFY_VARIABLE", and then all of the calls that specified the ADD_VARIABLE flag wouldn't need to actually be changed, although they would no longer actually be capable of adding a variable

(ugh, I hope that was clear I'm extremely tired and feel like I can't express myself well at all right now.)

It also means that you only need to change one function or that changing one sub-function/method will not affect the others.
The overhead will be pretty minimal but there is always a balance between readability and overhead.
Obviously you can set CONST for the flags so
const OBJECT_NOT_EXIST=0
const OBJECT_EXIST=1
contst CREATE_OBJECT=2
You can also expand easily by adding another const/flag and then another subfunction by expanding the SELECT/CASE.
SELECT / CASE can be ordered so most frequent options are placed at the top and least frequent at the bottom.
Long function calls are not a problem for people 'using' the code. If you're expecting people to look at your code in-depth or maintain the code then comments (e.g 'Calls' and 'Called by' statements) and/or UML (or other diagrams) will help.