Code Organization - Categorizing Variables and Functions

[Platypi]

I'm looking for a clean and common-place way of organizing/categorizing variables and functions. In otherwords, I want a method for clearly separating variables and functions that belong to one add-on from those in another. This is mostly for the sake of readability avoiding name conflictions. I'm not talking about making them invisible; just distinct.

Namespaces sound like they may be able to work to this extent. However, I'm not entirely clear on the concepts of objects and classed. It's been awhile since I've used any object-oriented language.

One thing I've seen in various add-ons is the use of "::" in variable names, preceded by some keyword that denotes which add-on said variable belongs to. For instance...

Code: [Select]

$RTB::Version = "4.05";
$RTB::Path = "Add-Ons/System_ReturnToBlockland/";
Now, I'm aware that namespaces use "::" in some regard. However, I've also read that it's possible to name a function or a variable with "::" without it being associated with a namespace. It seems to me that the example I've given utilizes the latter property, based on the use of the global variable sign, '$'. Am I correct in assuming this? Could it go either way? Whichever case it is, is it good practice?

P.S. I apologize for having asked two questions in one post. Although, I figured it be a bit redundant to create another topic for two inquires so closely related.

[Ad Bot]

[PhantOS]

The namespace $ :: thing or whatever it's called (I actually do not know the formal/technical name) functions as a fake directory for global variables. Similar to filepaths (Blah/Stuff/Content) the :: function as a new directory or subcategory for the global variable. There is a method that you can research a bit that allows you to load up the base global variable in a script, so that instead of using the variable $RTB::Prefs::WindowSize you can actually skip the $RTB::Prefs part and whenever the variable $WindowSize is used, it will actually be compiled as $RTB::Prefs::WindowSize

I haven't worked with Torquescript in 2 years, so I'm pretty rusty on it and actually trying to get back into it myself, but I know that this is a thing.

As for the other question, i really don't know. Namespaces aren't used the same way in Torquescript. your best bet is to use Parented Global Variables, such as the one I gave an example for.

[PhantOS]

Actually scratch that let me give a better explaination:

Code: [Select]

$MyScript::Fruit::Apples::Green = 1;
$MyScript::Fruit::Apples::Red = 0;
$MyScript::Fruit::Oranges = "Delicious";
$MyScript::Fruit::Bananas = "Ew";

$MyScript::Veggies::Lettuce = "Ew";
$MyScript::Veggies::Carrots = "Good for eyes";

$MyScript::Candy = false;

This is an example of parented global variables. It's a form of hierarchy of variables that is purely user-intended and shortens the time that the script will parse the variables. They are still global variables and will function like such. However, there is a 'way' to create a default path for the variables, so instead of there being a $MyScript in front of every variable, it will skip over to the next category after it when the script is executed.




Namespaces:

Namespaces function similar to parenting variables, except they are functions, and are meant to perform a certain task/function instead of hold a value. In order to use namespaces correctly:

Either create a new group that is a child of the virtual object SimGroup, like so (This is only one of many ways to do this):

Code: [Select]

$myGroup = new SimGroup(myGroup)
{
     thCIAAnExampleVariableThatIsAssignedToThisGroupAndIsCustom = "Hi";
}; //REALLY IMPORTANT! CREATING GROUPS REQUIRES A SEMICOLON AT THE END

In this case, to get the value of the method that we included inside the group, you simply do it like this:

Code: [Select]

$myGroup.thCIAAnExampleVariableThatIsAssignedToThisGroupAndIsCustom;

RETURNS: "Hi";

OR:

Code: [Select]

myGroup.thCIAAnExampleVariableThatIsAssignedToThisGroupAndIsCustom;

RETURNS: "Hi";


Here's some more stuff on it in case you need help:

http://docs.garagegames.com/tge/official/content/documentation/Reference/Introduction/Namespaces.html

[Headcrab Zombie]

With variables, namespaces are probably the best name to describe them. However, they're just variable names. There is no sort of "using namespace" statement that other languages have; meaning you can't having a variable named "$MyAddon::Thing::A" , declare "using namespace $MyAddon" and then just access "$Thing::A"

Functions are different though. double colons is permitted only once in a function name, and they're used for methods; you name them in the pattern ClassName::FunctionName and then you make a new script object (or some other types) $test = new ScriptObject() { class=ClassName; }; and call $test.FunctionName()

shortens the time that the script will parse the variables.

No it doesn't. It's nothing more than a name

However, there is a 'way' to create a default path for the variables, so instead of there being a $MyScript in front of every variable, it will skip over to the next category after it when the script is executed.

Was this supposed to be a question?
The answer is no, there is not

[Platypi]

These posts seem to answer my questions for the most part. However, I would like to know, what are some other common-place ways for organizing code in general?

[Ipquarx]

These posts seem to answer my questions for the most part. However, I would like to know, what are some other common-place ways for organizing code in general?

If you have tons of code (Like 2000+ lines of code) then it's best to organize it into different files, like putting all functions related to File IO in an "IO.cs" file and datablock definitions in "Datablocks.cs," etc. If you're making an addon in specific, if there are lots of other files you can just put all the necessary global variables into the server.cs file and then execute all the other cs files in whatever order necessary. (Though whether you want to put all global variables in 1 spot or in the files which they're related to is up to you)

[Greek2me]

These posts seem to answer my questions for the most part. However, I would like to know, what are some other common-place ways for organizing code in general?

This is what I'm doing currently: https://bitbucket.org/Greek2me/slayer/src/7eaa4aee5f66140dcd7eb0f04dd49b1425427408/server/?at=dev
20-something thousand lines

[boodals 2]

I highly recommend mod creators to name their functions with a mod ID of some sort to start with. I always do function BRPG_XXX when working on my RPG, function Bood_XXX when working on my server utils add-on, etc. It really pisses me off when you see large scale add-ons using function names like doCleanup(). Do clean up on what? What is it cleaning? What does the function do? But also because it makes it very easy to overwrite functions, which is very hard to detect in torquescript, but can cause add-ons to totally stop working as expected.

[Zeblote]

There is a method that you can research a bit that allows you to load up the base global variable in a script, so that instead of using the variable $RTB::Prefs::WindowSize you can actually skip the $RTB::Prefs part and whenever the variable $WindowSize is used, it will actually be compiled as $RTB::Prefs::WindowSize

I doubt this. Give an example.

[Swollow]

I highly recommend mod creators to name their functions with a mod ID of some sort to start with. I always do function BRPG_XXX when working on my RPG, function Bood_XXX when working on my server utils add-on, etc. It really pisses me off when you see large scale add-ons using function names like doCleanup(). Do clean up on what? What is it cleaning? What does the function do? But also because it makes it very easy to overwrite functions, which is very hard to detect in torquescript, but can cause add-ons to totally stop working as expected.

all my functions are hella swol

[PhantOS]

I doubt this. Give an example.

it's called Hash Tables. You can do something along the lines of $RTB::* or something.

[Ipquarx]

it's called Hash Tables.

Hash tables are a kind of data structure, which likely has nothing to do with the feature you're describing.

[Headcrab Zombie]

Hash tables are a kind of data structure, which likely has nothing to do with the feature you're describing.

In computing, a hash table (hash map) is a data structure used to implement an associative array, a structure that can map keys to values.

C# example:

Hashtable favorites = new Hashtable();
favorites.Add("color", "blue");
favorites.Add("food", "chicken wings");
favorites.Add("animal", "fox");

Console.WriteLine(favorites["color"]);

Output: "blue"


In TorqueScript, this is completely irreverent (and thus don't exist) because of the way arrays work:

$Favorites["color"] = "blue";
$Favorites["food"] = "chicken wings";
$Favorites["animal"] = "fox";

echo($Favorites["color"]);

Output: "blue"