Works with one thing but not the other?

[MadByte]

Why not simply reset the angle to 0 when it get's bigger then 360 ?

[NightKawata]

Also, don't require from within the love.load function. Require from the top of the main.lua and don't require main. It's already being run.

Besides requiring main, there really isn't too many faults for requiring files from within love's load function. iirc Mari0 also does the same thing, and it works fine. (Doesn't mean it's good per se, but I don't see the huge issue for doing that. Meh.)

[slime]

In fact, requiring from inside love.load means code in the required files will use the same proper randomseed that gets applied just before love.load. It also means any print statements in those files will properly output to the console in windows (in 0.9.0 this is fixed so that print will work before love.load.)

[Robin]

In fact, requiring from inside love.load means code in the required files will use the same proper randomseed that gets applied just before love.load. It also means any print statements in those files will properly output to the console in windows (in 0.9.0 this is fixed so that print will work before love.load.)

There's the answer why requiring inside of love.load() is a bad idea. Alright, it's not so much a "Wrong" as something that hides badly designed code (as in the above, for instance). It is my opinion that you need to have a very good reason to have anything at the top level of your modules other than assignment statements (function declarations fall under assignment).

[slime]

In fact, requiring from inside love.load means code in the required files will use the same proper randomseed that gets applied just before love.load. It also means any print statements in those files will properly output to the console in windows (in 0.9.0 this is fixed so that print will work before love.load.)

There's the answer why requiring inside of love.load() is a bad idea. Alright, it's not so much a "Wrong" as something that hides badly designed code (as in the above, for instance). It is my opinion that you need to have a very good reason to have anything at the top level of your modules other than assignment statements (function declarations fall under assignment).

So you basically want to defer code from the top level into a function, just for the sake of having it in a function? Not all code is designed to be executed multiple times during the program's lifetime, not to mention both the issues I mentioned above will cause some serious headaches if you don't already know about them.

[T-Bone]

In fact, requiring from inside love.load means code in the required files will use the same proper randomseed that gets applied just before love.load. It also means any print statements in those files will properly output to the console in windows (in 0.9.0 this is fixed so that print will work before love.load.)

There's the answer why requiring inside of love.load() is a bad idea. Alright, it's not so much a "Wrong" as something that hides badly designed code (as in the above, for instance). It is my opinion that you need to have a very good reason to have anything at the top level of your modules other than assignment statements (function declarations fall under assignment).

I'm not sure I understand you correctly... Isn't requiring modules outside of functions putting things at the top level of modules, which you say should be avoided?

I've always thought that putting as much as possible inside functions is good practice. Requiring things from within functions (like love.load) seems to me like the correct way of following that practice.

[RunningGamesStudios]

Why not simply reset the angle to 0 when it get's bigger then 360 ?

But if it changes the angle by let's say 4 once it goes over 360 insted of setting back to 4 it will go to 0

[Robin]

That's what % is for.

Code: Select all

180 % 360 == 180
359 % 360 == 359
360 % 360 == 0
364 % 360 == 4

I'm not sure I understand you correctly... Isn't requiring modules outside of functions putting things at the top level of modules, which you say should be avoided?

Well, of course calls to require as well (and a single return statement at the end, returning the module dictionary). But that's basically it.

This structure means that all dependencies are in place before you do anything that could need those dependencies. It makes things simpler by not having to see calls to require as flow control and "active code" that crosses file/module boundaries. Instead you can see them as passive declarations of dependencies, similar to Java (or, as a closer comparison, idiomatic C/C++, Go or Python).

Again, I shouldn't have called what RunningGamesStudios did with using require in love.load() "wrong" (even though it fit so nicely in the numbered list). I would still advice against it, though.

[RunningGamesStudios]

That's what % is for.

Code: Select all

180 % 360 == 180
359 % 360 == 359
360 % 360 == 0
364 % 360 == 4

I'm not sure I understand you correctly... Isn't requiring modules outside of functions putting things at the top level of modules, which you say should be avoided?

Well, of course calls to require as well (and a single return statement at the end, returning the module dictionary). But that's basically it.

This structure means that all dependencies are in place before you do anything that could need those dependencies. It makes things simpler by not having to see calls to require as flow control and "active code" that crosses file/module boundaries. Instead you can see them as passive declarations of dependencies, similar to Java (or, as a closer comparison, idiomatic C/C++, Go or Python).

Again, I shouldn't have called what RunningGamesStudios did with using require in love.load() "wrong" (even though it fit so nicely in the numbered list). I would still advice against it, though.

I don't get how I would use that to correct the angle though

[jasonisop]

I don't get how I would use that to correct the angle though

Is there a face palm smiley?