Quenty
|
  |
| Joined: 03 Sep 2009 |
| Total Posts: 9316 |
|
|
| 15 Dec 2011 04:34 PM |
Does using local for defining variables in the top of a script (in the script's scope) really matter?
like...
local x = true local y = 3.24 local n = 3.53
Or would it be, technically, better to do...
x = true y = 3.24 n = 3.53
Since they are in the same scope anyway. Basically, is local necessary for variables in the scripts scope.
Also, would it be better to define all my variables in a table incase I need to use setfenv()?
It's a love-hate relationship.... |
|
|
| Report Abuse |
|
|
NVI
|
  |
| Joined: 11 Jan 2009 |
| Total Posts: 4744 |
|
|
| 15 Dec 2011 04:37 PM |
I think it looks better, but that's just the strongly-typed coder in me.
As for actual implementation, I'm not sure. |
|
|
| Report Abuse |
|
|
LocalChum
|
  |
| Joined: 04 Mar 2011 |
| Total Posts: 6906 |
|
|
| 15 Dec 2011 04:38 PM |
| I just like the look of it, really... |
|
|
| Report Abuse |
|
|
| |
|
stravant
|
  |
 |
| Joined: 22 Oct 2007 |
| Total Posts: 2893 |
|
|
| 15 Dec 2011 04:48 PM |
If they're local variables then all operations on them will be significantly faster than operations on the non-local equivalents. It will make a noticeable difference if you do some number-crunching where you need to access them frequently.
Also, if you make them local variables you can turn on strictness in your script without any problems popping up, while making the code easier to debug. |
|
|
| Report Abuse |
|
|
Quenty
|
  |
| Joined: 03 Sep 2009 |
| Total Posts: 9316 |
|
|
| 15 Dec 2011 04:50 PM |
I mean at the top of a script. I use local variables in everything else..
So.... like ************************************************* 1) DEFINE (What I'm talking about)
2) FUNCTIONS
3) EXECUTE ************************************************* That is the order of my scripts. Would it be better to define in local variables at the top?
It's a love-hate relationship.... |
|
|
| Report Abuse |
|
|
Pyzothon
|
  |
| Joined: 26 Oct 2011 |
| Total Posts: 822 |
|
|
| 15 Dec 2011 05:24 PM |
Not sure. I saw a question like this in Scripting Helpers, but it was never answered.
Pyzothon, novice scripter/programmer. |
|
|
| Report Abuse |
|
|
stravant
|
  |
 |
| Joined: 22 Oct 2007 |
| Total Posts: 2893 |
|
|
| 15 Dec 2011 05:26 PM |
"That is the order of my scripts. Would it be better to define in local variables at the top?"
No, it would be best to define them closest to whatever code uses them. |
|
|
| Report Abuse |
|
|
Quenty
|
  |
| Joined: 03 Sep 2009 |
| Total Posts: 9316 |
|
|
| 15 Dec 2011 05:30 PM |
No no... I do that. I mean like variables used through out the script. -_____-
Here's an example:
--Start of defining variables... local Control = script.Parent local Config = Control.Config local Design = Control.Design local Color = Design.Color local CDrag local Domain local Dialog local Catch local Highlight
local vDialogDisplayed = Config.DialogDisplayed local vExtendedPalette = Config.ExtendedPalette local vSelection = Config.Selection
local selection = vSelection.Value local dtext = Design.DisplayText.Value local changed = false local dmult = 8 local absP local nabsS
local extendedcolors = {} for i = 0,1032 do local b = BrickColor.new(i) if i == b.Number then table.insert(extendedcolors,b) end end local palcolors = {} for i=0,63 do table.insert(palcolors,BrickColor.palette(i)) end local currentcolors = palcolors
event = {} function disconnect(set) for _,index in pairs(set) do if event[index] then event[index]:disconnect() event[index] = nil end end end
local BrickColorPicker = script.Parent BrickColorPicker.BorderColor3 = Color.Border.Value BrickColorPicker.BackgroundColor3 = Color.Background.Value local oColorName if dtext then oColorName = Instance.new("TextLabel") oColorName.BorderSizePixel = 0 oColorName.Size = UDim2.new(0.8, -4, 1, -4) oColorName.FontSize = Enum.FontSize.Size9 oColorName.Font = Enum.Font.Legacy oColorName.TextColor3 = Color.Text.Value oColorName.BorderColor3 = Color.Hidden.Value oColorName.Text = vSelection.Value.Name oColorName.TextXAlignment = Enum.TextXAlignment.Left oColorName.Position = UDim2.new(0, 2, 0, 2) oColorName.TextWrap = true oColorName.Name = "ColorName" oColorName.BackgroundColor3 = Color.Background.Value oColorName.archivable = false oColorName.Parent = BrickColorPicker end local oColor = Instance.new("Frame") oColor.Size = dtext and UDim2.new(0.2, -3, 1, -6) or UDim2.new(1, -6, 1, -6) oColor.BorderColor3 = Color.Border.Value oColor.Position = dtext and UDim2.new(0.8, 0, 0, 3) or UDim2.new(0, 3, 0, 3) oColor.Name = "Color" oColor.BackgroundColor3 = vSelection.Value.Color oColor.archivable = false oColor.Parent = BrickColorPicker local MouseClick = Instance.new("ImageButton") MouseClick.BorderSizePixel = 0 MouseClick.Size = UDim2.new(1, 0, 1, 0) MouseClick.BorderColor3 = Color.Hidden.Value MouseClick.AutoButtonColor = false MouseClick.BackgroundTransparency = 1 MouseClick.Name = "MouseClick" MouseClick.BackgroundColor3 = Color.Hidden.Value MouseClick.archivable = false MouseClick.Parent = BrickColorPicker
function GetDomain(object) ... end
function GetExtendedDialog(domain) ... end
It's a love-hate relationship.... |
|
|
| Report Abuse |
|
|
smurf279
|
  |
| Joined: 15 Mar 2010 |
| Total Posts: 6871 |
|
|
| 15 Dec 2011 05:47 PM |
"No, it would be best to define them closest to whatever code uses them."
Meh, its more about prefrence if you ask me. I like to have my variables at the top so its search for what I'm looking for like in a table of contents or gloassary but for my smaller scripts I don't really care. |
|
|
| Report Abuse |
|
|
smurf279
|
  |
| Joined: 15 Mar 2010 |
| Total Posts: 6871 |
|
|
| 15 Dec 2011 05:55 PM |
| @Quenty Local variables are accessed faster than normal variables so it'd probably be better |
|
|
| Report Abuse |
|
|
|
| 15 Dec 2011 06:27 PM |
Quenty, you could've just tested it:
x = 3 for i = 1, 1000000 do y = 5 end
local x = 3 for i = 1, 1000000 do y = 5 end
I got absolutely no speed difference. But I like the look :D |
|
|
| Report Abuse |
|
|
Quenty
|
  |
| Joined: 03 Sep 2009 |
| Total Posts: 9316 |
|
|
| 15 Dec 2011 06:29 PM |
Align all your equal signs with tab... It looks REALLY good.
It's a love-hate relationship.... |
|
|
| Report Abuse |
|
|
smurf279
|
  |
| Joined: 15 Mar 2010 |
| Total Posts: 6871 |
|
| |
|
smurf279
|
  |
| Joined: 15 Mar 2010 |
| Total Posts: 6871 |
|
| |
|
|
| 15 Dec 2011 06:32 PM |
Be quiet, smurf! Wow. Using local is a lot faster. At least I did (try to) test it, unlike Quenty =P |
|
|
| Report Abuse |
|
|
|
| 15 Dec 2011 07:22 PM |
I tested local vs. nonlocal variables. It doesn't make much of a difference in most scripts, but if you try using a variable 1e7 times at once, then local is about 1 second faster, I think. I made a script that tests this stuff out for me. I also found:
-for loops are faster than making your own variable and incrementing it in a while loop. -Using [[blah = (function() return "Blah" end)]] is much faster than calling a function that you made before. -Localizing all global variables make a HUGE difference. -Getting a value from a table isn't much slower than getting a variable.
I had a lot more, but I forgot them.
|
|
|
| Report Abuse |
|
|
|
| 16 Dec 2011 03:42 AM |
| if Roblox had include() in it, it would matter but I don't think it does |
|
|
| Report Abuse |
|
|
Oysi
|
  |
| Joined: 06 Jul 2009 |
| Total Posts: 9058 |
|
| |
|
pwnedu46
|
  |
| Joined: 23 May 2009 |
| Total Posts: 7534 |
|
|
| 16 Dec 2011 01:48 PM |
I don't use them for efficiency as much as I do because I'm so used to typing a datatype like in C++ and Java that it just looks weird, as NVI said. The difference in efficiency between local and nonlocal variables is negligible.
---------- ~ pwnedu46, the unicorn ~ |
|
|
| Report Abuse |
|
|
|
| 16 Dec 2011 04:27 PM |
personally, I find this format to work the best, in terms of code cleanliness:
----- Define Script Global Variables ------- local globalVar = 5
----- Define all functions ------------------- function addToGlobalVar(num) if type(num) == "number" then globalVar = globalVar + num else print("Error: addToGlobalVar expects num, got",num) end end
----- Define Actual Script Start Code ------- addToGlobalVar(5) print(globalVar) |
|
|
| Report Abuse |
|
|
|
| 16 Dec 2011 04:27 PM |
| except you should use indentation.... |
|
|
| Report Abuse |
|
|
|
| 16 Dec 2011 04:29 PM |
| Local variables at the top of the script work exactly the same as global variables. You should use local variables all the time because it's more efficient. |
|
|
| Report Abuse |
|
|
NVI
|
  |
| Joined: 11 Jan 2009 |
| Total Posts: 4744 |
|
|
| 16 Dec 2011 04:30 PM |
Plus, local is a nice word.
locallocallocallocallocallocallocallocallocallocallocallocal |
|
|
| Report Abuse |
|
|
|
| 16 Dec 2011 04:57 PM |
Yes, it matters. Using local variables instead of global variables is faster. Even at the top of the script.
Here's a part of LuaDate 2.0.1 :
--[[ LOCAL ARE FASTER ]]-- local type = type local pairs = pairs local error = error local assert = assert local tonumber = tonumber local tostring = tostring local string = string local math = math local os = os local unpack = unpack local setmetatable = setmetatable local getmetatable = getmetatable
Yep. They're literally redefining globals as locals. A waste of memory, you say? Well, you're right, it's a waste of memory, but it's also a gain of speed... |
|
|
| Report Abuse |
|
|