NO! Then you would have a HUGE main.lua file with so many lines I WOULD NEVER READ!
The best way to do stuff is organizing things, player code and monster code is different, the main menu is not part of the game mecahnics... and so on. Of course there would be some files that would interact with others, for example you could have a main.lua file that requires menu.lua and game.lua, game.lua would require monster.lua and player.lua and so on
If your player is not going in the right direction, the only file I should look to fix it should be player.lua since no other file should modify the player direction, if the problem is not there I would go up a level to game.lua which handles the actual game mechanics and updates my player.lua, if the error is not there I should go up a level and check that my main.lua file is sending the rights events to game.lua.
If you read that I never had to check my monster.lua file or menu.lua file, since they don't have anything to do with the code I wrote for the player, they do their own stuff. This is encapsulation.
Files should handle only one thing (monster, player, game, menu, options, levels), in those files there should be module tables or classes, the first one is just a table with many functions it may have some internal state but keep it as little as possible if you can (since this is hard to debug), the second one is a class generated with a class library which I can use to replicate an object, for example I could have a monster class to spawn multiple instances of the monster object around the level.
Functions should do one thing and one thing only, the idea is that a function shouldn't be doing too much, if a function does too much you can't reuse it, say if I have a function that checks collisions, it should not handle collisions itself, it should instead call other functions that handle the collision (in the first case the player is colliding with a monster so I run check collisions and I get that the player is colliding with a monster and substract 5 from the health, what would happen if its colliding with a wall? I would have to write another function that checks collisions and then instead move the player so that it stops colliding, in the second case check collisions would only check what the player is colliding with, then I would see if I need to move it or substract 5 from his health)
Use locals!, If you use global variables you can't use the same name, say I have a configuration table which is global and handles global configuration say sound and graphics, players.lua also has got a configuration table which is global and has the very same name, but this one is only used to configure the player speed and some internal stuff, the first table would be overriden with this one and that is NEVER what you want, it's really hard to debug this problems since the code is totally valid, but it won't be doing what you want!
I must recommend
this series of blog posts that was written by a developer (
Kikito) that made some really nice modules for LÖVE and Lua (Bump, Middleclass, Gamera, Love-loader and so on) I must say that he doesn't always follow his own advice but doing so would result in far better libraries nonetheless (love-loader!!!)
gameFiles.love