actually i got better idea on Services metatable thing
here:
local Services = setmetatable({},{
__index = function(self, ind)
if pcall(function() game:GetService(ind) end) then
rawset(self,ind,game:GetService(ind))
return game:GetService(ind)
end
end
})
I know i added just only one line of code
but then __index wont need to be called a milion times instead the service gets cached
I find that it’s a lot easier to code a tough feature while I’m working in that one particular module in the moment. Then when I want to use it somewhere else, I already have that feature made, so I don’t need to worry about coding it. It gives me creative freedom as I don’t need to stop what I’m doing to code this thing, which will bore me. For me, this is usually done by trying to keep private methods public for more flexibility.
Later, if I notice that I never used it, then I’d delete it. Or if I try to use it and it doesn’t work, I end up removing it unless it’s a simple fix!
Kind of like this:
There’s more to this, though. If you fixed a bug by using task.wait(), than it’s unreliable. A simple wait should not fix any problem. It’s better to understand precisely what is causing the issue by debugging. That’d be much more optimized, faster, and of course reliable!
I love templates too!
Too bad! This way is prettier! 
Even ForeverHD does this (TopbarPlus), but that’s not why I do.
Not going to argue about this! It has worked for me literally forever (apart from very rare cases where I use ReplicatedFirst)! 
These are all great tips! I prefer to use PascalCase for function names, but that’s just personal preference.
fair, fair, that may be better
Not sure if I understood what you were trying to get at here. If you could rephrase this that would be great. Again, these are practices that are widely used across professional environments. I can’t dictate whether you like them or not.
This topic isn’t just about making certain aspects of code “prettier.” It’s mostly about the most optimal solutions. If you don’t want to use GetService, that’s not my problem.
I’m not sure if I understand what you’re saying here. I never said you should resort to using waits for fixing bugs. I said to use task.wait() instead of wait()
However, I like the choice of emojis in your reply.
Read the OP, it talks about a general standard across the programming world. Not in Roblox or Lua/luau. Besides this doesn’t name camel case as THE standard, it outlines several standards depending on what you’re naming.
Lastly, this is not an official or widely referenced thing so I’m unsure what your point even is?
He means for Roblox generally. camelCase is recommended for variables and functions while PascalCase is recommended for module names and methods.
He means for Roblox generally. camelCase is recommended for variables and functions while PascalCase is recommended for module names and methods.
There are numerous different naming conventions. However, camalCase is widely recognized as the generally accepted convention across the programming world.
Amazing you think he means roblox generally when that’s quite literally not what he says. And again, even in Roblox it’s not that simple. Constants are a variable, local and global variables are also obviously variables. Yet a different style is commonly used when naming each of the three.
He MEANT. He slipped some things when writing this, like :once instead of disconnects, and other stuff.
And as I said, even if it only said in Roblox, it’s still a lackluster and very incomplete explanation that completely misinforms the reader.
That is very useful, i will certainly read this while waiting for my game to load while playtesting
Imo I don’t really like camelCase and feel as though it might be just a tad harder to read. I prefer PascalCase or snake_case because they have a bit of separation of where a word starts and ends. If I were to recommend a casing style to maybe someone who is starting out it would probably be one of the aforementioned casing styles because like I said earlier it’s just a bit easier to read in my experience. At the end of the day something like a naming convention is pretty subjective and everyone has their own style.
In terms of the other practices such as: effective naming, guard clauses, type checking, comments, etc are good practice as a whole even in other languages. Couple things I did notice were not part of the thread would be: removing unnecessary nesting, and consistent styling.
Unnecessary Nesting is a problem for many reasons but the biggest one is readability. Some games that I have worked on have been horrible in this regard and it had caused big time burnout for me, because I just never knew where anything was and it just became super time consuming.
Consistent Styling is a lot easier when you use something like a Rojo based workflow because of tools like StylLua, Selene, Luau-LSP, etc. If you aren’t using that type of workflow I believe there are some WIP projects that are going to help with this immensely.
Something relating to frameworks, while they can be very useful for keeping a good & strict structure it sometimes can hurt the project more than benefit. I couldn’t find the post by sleitnick (the person who made Knit and AeroGameFramework) but it had a lot of interesting points relating to Knit’s usefulness as a framework and something that really stuck with me from that article was talking about taking something like a car and adding wings to it. That was in relation to I think the AeroGameFramework → Knit. I can’t remember the whole thing but if you feel comfortable using a framework like Knit then you should, if you want to make a framework that is tailored to the project you should.
Overall some areas of the thread could be improved but I think that this is definitely a good resource for someone starting out on their programming journey!
You can do the same thing without using a framework. That’s what modulescripts are for. In fact, I would say frameworks such as Knit make things worse, because it requires you to code things specifically for Knit. Granted, changing the modules to work without Knit wouldn’t be too difficult, but you still would need to edit it.
