Are there any advantages of using tables for configs/other stuff?

This is hard to explain. In code I see a lot of things like:
[lua]foo = {}

foo.config = {}

foo.config.hue = “hmm”
foo.config.hue2 = “hi”
– etc[/lua]

are there any functional advantages to that, as opposed to


fooconfighue = “hmm”
fooconfighue2 = “hi”
– etc[/lua]
I’m going to work on a system will probably use a lot of tables… But why I ask would things like this be useful besides ‘making it look pretty’?

Because more config tables = better code, apparently.

Less probability for conflicts if its all in one table.

Polluting the global namespace should generally be avoided as a best practice. As StonedPenguin mentioned, one of the reasons is to avoid any possible conflicts with other addons.

also imo it is easier to remember the names and for debugging. You can easily check with PrintTable if the config is right, especially when you set configs outside of an config.lua.

Because you’re asking quite a few questions lately, I’ll dive a bit deeper into the explanations. Hopefully this helps:

For files where the config is used locally and isn’t a lot, it won’t matter ( you’re limited to ~200 locals per “scope” ). I agree with #3, 4 and 5 too…

Don’t ever hard-code numbers; use a CONST ( a variable, typically written in all uppercase, of which the value never changes, languages that have a CONST data-type-descriptor should limit the ability to change the value and give an error after it has been defined ). For example, source units to inches = 4 / 3 and feet = ( 4 / 3 ) * 12; instead of typing that every where, write something like UNITS_PER_INCH = 4 / 3; UNITS_PER_FEET = UNITS_PER_INCH * 12; UNITS_PER_METER = UNITS_PER_FEET * 3.28084;

ENUMs or Enumeration is “related” to a CONST, but instead of storing a “useful” value, it stores an “idea” [ termed loosely ]. By that I mean the variable becomes the toggle instead of the value although the value is important in its own way, it isn’t the thing the programmer should need to worry about, and the value should be different where multiple toggles are used in the same context. Example, this helper-function with 3 examples to load a file: which uses 0 1 and 2 for client, server and shared realms, but instead of needing to remember which number goes where, or needing to compare “client”, “server”, “shared” strings, we can just use a variable everywhere we need to.

And, what I mean by in the same context where the value must be the same is: 0, 1, and 2 can be re-used for different enumerations ( for something that isn’t related )… So, instead of defining the realm, it could define the data-type ( which is how net.WriteTable / net.ReadTable works… by sending a data-type table in front of the data, so it knows which type to read next )