Best Practices Handbook

[TimeFrenzied (Chicken Jockey)]

A meme.

It’s not a bad method to use, but it’s surely laughable. (that being said im using it haha)

[TimeFrenzied (Chicken Jockey)]

@CodedJack

Do not use the second argument of instance.new to set the parent of an object.

-- What not to do
local newPart = Instance.new("Part", workspace)

Instead, you should always set the parent property last:

-- What to do
local newPart = Instance.new("Part")
newPart.Name = "My Part"
newPart.Parent = workspace

This is not just some formatting convention. If you don’t set the parent argument last, you will not get the desired performance. In fact, most Roblox core scripts and tools use this bad practice…

Can you explain this a little bit more for beginners? The announcement may be hard to understand for some. (edit: all you really need to do is give a mini explanation on why, or people are gonna keep doing it anyway)

[CodedJack (jack)]

Yea good point, I’ll update that section in a bit.

[Coolsbloxian]

@CodedJack

CamelCase

Wouldnt it be spelled “camelCase”?

Super neat handbook, tysm

[CodedJack (jack)]

Good catch, I’ll fix that. I dont want to be using incorrect camal casing in my camal case section

[TimeFrenzied (Chicken Jockey)]

@CodedJack

Let’s say you only need this code to run once. After the first time this code runs, it will be useless to you. And, this connection will still be in memory. It’s only until the part get’s deleted will the connection get garbage collected.

Let’s go ahead and fix this problem:

local connection
connection = part.Touched:Connect(function()
	connection:Disconnect()
	-- // Do stuff //
end)

Now, this touched event is only in memory until the first time it’s touched.

You should also teach about :Once() instead of just Connect and Disconnections.

[CodedJack (jack)]

Oh yea, I remember thinking about that last night. Although I must have fell asleep before writing it. I’ll add it now.

[Rythian2277 (Rythian)]

A few notes I’d like to say, this isn’t meant to be negative but just to add information so the community has as much information as we can pool as a collective

---

@CodedJack

However, camalCase is widely recognized as the generally accepted convention across the programming world.

camelCase has been phased out in the in-engine API in favour for PascalCase, Destroy not destroy and so forth, code which has public methods should ideally be using PascalCase for those methods for consistency with the engine itself

---

@CodedJack

Guard clauses are conditionals that exit a function/loop with a return/break/continue statement.

It would also be nice to add information about assert as a way to add guard clauses, baring in mind that if the first argument is false or nil, it will throw the second argument as an error

assert(game.Workspace:FindFirstChild("Baseplate"), "Baseplate does not exist.")

---

@CodedJack

Module Scripts are arguably the most useful script object in Roblox.

I 100% agree with this, perhaps an inclusion of the basics of how the self keyword works, especially since you use it in the returnCoolString function and might confuse a few people haha

---

Hopefully these few extras might help even just a handful of people

[CodedJack (jack)]

This is definitely useful information, I’ll probably edit this post tomorrow to include some of these ideas.

[thebigkannye]

There’s hardly an agreement on camel case being the standard, and either way it’s usually used in conjunction with pascal case and sometimes snake case (especially upper case for constants) depending on the specific thing you’re naming. Like is it protected, private, public? Is it a function? Is it a class? Is it a constant? Is it a file? Etc etc. The standard widely varies by programming language, and then of course projects and libraries within that language too.

The segment on functional programming is a bit far off too. Functional programming is quite a bit more complex and pretty hard to explain, it also varies a lot depending on who you ask.

If were talking about pure functional programming, which is often what people refer to these days when they use the term, it’s mainly about minimizing side effects and making functions deterministic. E.g if you call a function with the same argument, it will return the same thing every time. Usually when we program there’s lots of times this doesn’t happen, for example if we use the value of the clock inside of the function to decide something, or a math.random().

As for other “rules”, there’s a lot of people who are big on what you kinda mentioned, which is not updating data. So instead of changing data, they favor creating a new data structure to contain that data when performing some sort of operation with it. Recursions are also seen as the go to over loops. Which obviously stems from the whole mathematical origin of functions. And then of course functions can be passed to other functions, returned, or assigned to variables, etc.

Now people often think that if you use some programming paradigm, that has to be the only programming paradigm that you use. That obviously makes zero sense, there’s strengths and weaknesses of OOP and functional programming, and nothing that prevents you from using them or other paradigms in the same project or even together in the same bits of code. For example recursion can be pretty sweet sometimes, but it can also be memory intensive as shit and fill up the call stack to the point of crashing ur program.

There’s also no one set of rules for any paradigm, most of them have at least one or several “sub paradigms”.

[Sorbious]

I’m glad I didn’t get lazy reading this because I just discovered the use of Knit Framework. I can now develop without messing with Remotes and stuff.

[Bakonowychlopak123]

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

[bluebxrrybot (blueberry)]

@CodedJack

You aint gonna need it…

Don’t write code that you think you will need in the future.
This is coding for imaginary future use cases that you think you will need.
90% of the time, you won’t need that code. And it will sit there.

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:

@CodedJack

Program with a mindset of scalability.
Don’t hardcode certain aspects of your code. This will lead to long hours of work if you plan your project to be bigger.

@CodedJack

task.wait instead of wait

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!

@CodedJack

Cloning instead of instancing

I love templates too!

@CodedJack

GetService instead of referring to services

Image

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)!

[sleitnick]

These are all great tips! I prefer to use PascalCase for function names, but that’s just personal preference.

[TimeFrenzied (Chicken Jockey)]

@Bakonowychlopak123

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

fair, fair, that may be better

[CodedJack (jack)]

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.

@bluebxrrybot

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)!

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.

@bluebxrrybot

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’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.

[commitblue]

@thebigkannye

There’s hardly an agreement on camel case being the standard,

https://roblox.github.io/lua-style-guide/#naming

[thebigkannye]

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?

[TimeFrenzied (Chicken Jockey)]

@thebigkannye

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.

He means for Roblox generally. camelCase is recommended for variables and functions while PascalCase is recommended for module names and methods.

[thebigkannye]

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.