[Phanx]

Most variables you create and use in the course of writing an addon should remain local. There are very few situations where a global variable is necessary or desirable. You should get to know what those situations are, and avoid using globals in any other situations.

Saved variables are necessarily global. If your addon uses more than ~3 saved variables, as in the example you posted, it's probably better to do as Resike said and switch over to saving a single table with all those things inside it:

## SavedVariables: AggroMonDB

AggroMonDB = {
     active = true,
     sound = true,
     chat = true,
     show = true,
     soundFile = "ds\\sound\\creature\\murloc\\mmurlocaggroold.ogg",
     enablePVP = false,
}

The names you give frames and other UI objects are also global:

CreateFrame("Frame", "MyFrame", UIParent)
MyFrame:CreateFontString("MyFontString", "OVERLAY")

A good rule of thumb here is to give global names only to:

(a) secure objects like action buttons,
(b) objects that inherit from a Blizzard templates like ActionButtonTemplate that expect a name, and
(c) your addon's main frame object.

For everything else, just pass nil where the Create* API accepts a name, and use local references:

local frame = CreateFrame("Frame", nil, UIParent)
local text = MyFrame:CreateFontString(nil, "OVERLAY")
frame.text = text

^ In your code, you'd want to use the "frame" and "text" variables; the last line just makes it possible to access the font string easily from outside that file, eg. with a /run command in-game.

Slash commands are also necessarily global:

SLASH_MYADDON1 = "/myaddon"

So are binding and binding header names:

BINDING_HEADER_MYADDON = "MyAddon"
BINDING_NAME_MYADDON_TOGGLEFRAME = "Toggle frame"

However:

Originally Posted by AlleyKat ... addon build-in table (like local t, n = ...; ADDON_NAME = n; )

This is incorrect for two reasons:

1. The values passed to your addon files are not globals. They're not even assigned to variables at all unless you assign them to variables yourself.

2. Your example is backwards; the first value passed into each file is the addon's folder/TOC name, and the second is a table. There's also no reason whatsoever to assign the value to "n" and then assign it to "ADDON_NAME" immediately afterwards, and your example is putting that "ADDON_NAME" in the global namespace, which is a horrible idea.

local ADDON_NAME, privateTable = ...

ADDON_NAME is a string, eg. "MyAddon" or "oUF_Phanx_Config", that matches the name of your addon's folder and TOC file.

privateTable is a table. It starts out empty, but you can add whatever you want to it, and those contents are then available in all of your addon's files, since all references point to the same table object.