Creating shortcut functions, is it bad form?

[Jasoco]

Is it bad faux pas to create shortcut functions that simply contain other functions for purposes of making them easier to remember?

For instance, currently I just use variables as shortcuts to the love.* functions like love.graphics and love.sound etc. But I want to make it even easier for myself by doing things like:

Code: Select all

function rectangle(...)
  love.graphics.rectangle(...)
end

function color(...)
  love.graphics.setColor(...)
end

Is this bad form? Or is it accepted for purposes of saving time? I mean "rectangle" and "color" are pretty easy to recognize. And I wouldn't use any reserved names.

[slime]

How is that different from doing

Code: Select all

rectangle = love.graphics.rectangle
color = love.graphics.setColor

?

I do a final optimization step in my code by doing the above, but localizing them to key blocks of code.

[bartbes]

How is that different from [...]

It's less efficient.

[Kadoba]

If you do create shortcuts then create them like slime did. And strictly speaking, yes your example is bad form but mostly because you're putting things directly in the global scope. However if you define shortcuts locally in each file it won't pollute the global scope, it will let you keep your shortcuts, it will be less confusing to the reader, and it will actually be marginally faster performance-wise.

[Jasoco]

If you do create shortcuts then create them like slime did. And strictly speaking, yes your example is bad form but mostly because you're putting things directly in the global scope. However if you define shortcuts locally in each file it won't pollute the global scope, it will let you keep your shortcuts, it will be less confusing to the reader, and it will actually be marginally faster performance-wise.

What exactly does "pollute the global scope" mean? And what would be different between making one global call to all these functions or a local call in every file?

[Kadoba]

Basically, reliance on globals make your program easier to break and more confusing to follow. They're relatively well behaved in lua but can still cause problems. Imagine somebody wanted to create a lua library and they have never heard of love2d and wanted to create, say, a voice networking library. They decide to call it "Linking Omega VoIP Environment" and they put all of their functions in a global table called "love". See the problem? Incorporating this library into a love2d game would be a real pain because the names would conflict. The more globals you use, the greater chance things like this will occur.

Now let's say I'm reading through your code and I come across where you used "color" set to "love.graphics.setColor". Well at this point I don't know what "color" means. I have a good idea from the context but I don't know for sure since I don't know where it is defined. So I scroll up through the file looking for "color" do a ctrl+f and realize it's not defined in the file. Well now where do I look? Unless you have a globals.lua file or something I'm lost. Once I find it I have to remember that "color = love.graphics.setColor" forever as long as I'm in your code. Add a dozen more names like these and it can be a real headache. Not to mention I could never use the global "color" for anything I would want to use it for. Globals make things known everywhere, across all files.

That being said I'm not saying you shouldn't use globals sprinkled about here and there, but most programmers consider frequent use of globals as bad practice.

A responsible way to use globals is to insert them all into a single table much like love2d does it and define them all in a single place. This way there's no ambiguity and you know exactly where to go to change something.

[kikito]

"polluting the global namespace" means "creating unnecessary global variables"

The "pollution" here is similar to satellite polution; the more satellites and debris you put in orbit, the more probable a satellite clash is.

Global variables are similar; The more global variables you use, the more possible is that two of those share the same name - one will override the other, and you will have a problem.

In some cases they are easy to find. If you have two "rectangle" global variables, probably one of them will throw an error when it gets passed the wrong type of parameters.

But it's not always so evident. Global clashes can be very subtle and take months to find. I have had that issue myself.

I experienced this issue not long ago, in LÖVE 0.6.x, when I created a global function called "debug". On that time, LÖVE itself was using that same global variable for handling error output, so I had in fact disabled error logs. Since I did not have an error immediately, I didn't notice the change. Then I got some crashes, but I didn't notice that the error logs where not appearing because the errors where quite obvious. And then, one month later, I really needed error reports and I discovered that I didn't have any. I spent 2 months without error reports, until I opened an issue on the tracker and the devs helped me.

Putting your variables inside namespaces (mypackage.myvar instead of a global myvar) and using local variables are good practices that prevent this kind of issue.

If you are making a library for others to use, it's specially important to limit the global namespace pollution, since you don't know what others will be using as global variables. If you can, use 0 variables (you can just return a table on the require).

I must also point out that, for the shake of efficiency, local variables are slightly faster than global ones. So this:

Code: Select all

rectangle = love.graphics.rectangle

is a bit slower than this:

Code: Select all

local rectangle = love.graphics.rectangle

In addition of being faster, the local variable is also a bit less "polluting", since it's global inside the file/scope where it's defined, but invisible outside. Its downside is that it must be declared on each file.

[bartbes]

On that time, LÖVE itself was using that same global variable for handling error output, so I had in fact disabled error logs.

Yup, since then there's a local in boot.lua to keep the debug table around, no matter what the program does. It was a pretty commonly occurring bug too.

As for whether this is bad, as said before, if it doesn't get out of hand (I dislike everything being a shorthand, because it severely decreases readability if I keep having to look things up), and you make them local to the file, so I can at least find them easily, this is no problem for me.
I've seen people create an 'lg' local for love.graphics, something that saves a lot on typing etc, but still makes sense. As ever, though, try keeping your variable names descriptive and/or logical.

[Taehl]

Personally, I like using this style:

Code: Select all

function love.draw()
	local lg = love.graphics
	lg.setColor(r,g,b, a)
	lg.draw(somegraphic, x,y, a, xs,ys)
end