As programmers, we all view each others code. Sometimes we complain and say that someones code is ‘messy’. This means that the code may work, but it’s very hard to read. For example, suppose we are making an admin command script. This is our code:

local adminz = {}

game.Players.PlayerAdded:connect(function(newd00d)

for dontcareaboutindex,string in pairs(adminz) do

if string == newd00d.Name then

newd00d.Chatted:connect(adminchat)

end

end

end)

This may run perfectly fine, but it’s incredibly hard to read. Some of the variable names don’t resemble what the name represents very well, while others are just plain ridiculous. There is a common approach in all programming languages to write cleaner, easier-to-read code. There are several methods to doing this, but in general, you want your variables with multiple words to have the following syntax: First word uncapitalized, the rest capitalized on the first letter of the word. For example, instead of calling the admin table list, adminz, we could call it this:

local adminList = {}

This looks much better on the eye, and now we know that it’s a list of admins, whereas the adminz variable is more vague. However, don’t get too specific. This would be a very bad variable following these rules, simply because it’s too long:

local adminListOfPlayersToGetCommands = {}

Keep things short, simple, and easy-to-read. Let’s move on to the next line:

game.Players.PlayerAdded:connect(function(newd00d)

This is totally fine, except for the player argument, newd00d. This isn’t a good variable at all. A better variable name for this would be player, which is what most people use:

game.Players.PlayerAdded:connect(function(player)

But what if we already have a variable for player used earlier for something else? Even though this player variable is local, so it won’t affect the other player variable, it will look just a bit messy. We can fix that by making the player variable more specific. Since the PlayerAdded event fires when a new player joins, this player variable represents a new player. So we can name it ‘newPlayer’ instead, specifically indicating that we’re talking about a new player that joined the game:

game.Players.PlayerAdded:connect(function(newPlayer)

This looks easier on the eye, and you know whenever you access a property of newPlayer, that you’re editing a new player that just joined.

The next line looks pretty ridiculous:

for dontcareaboutindex,string in pairs(adminz) do

For starters, we renamed adminz adminList, so let’s fix it up:

for dontcareaboutindex,string in pairs(adminList) do

Now, the index and value variables in this iteration each are bad for different reasons. The index variable, dontcareaboutthisindex, is bad because it’s too long, and the value variable, string, is bad because it’s too vague. The conventional method for this loop is to use i for the index, and v for the value, but those are too short and too vague. Imagine if you have for loops inside for loops, and for some reason you want to get the index of the previous for loop in the one inside. It can get pretty confusing, unless you name these better. However, if we’re not using the index for anything, which is very common in this kind of loop, we don’t really need the index. A common convention to get rid of the index is to use ‘_’ instead. However, if we are using the index, we should make a better variable name, like adminIndex. Let’s modify the line:

for adminIndex, string in pairs(adminList) do

Doesn’t that already look so much better? Only one thing left to modify, the string. Since the string is reffering to the names of all the admins, we can replace that with the variable adminString. Let’s do that right now:

for adminIndex, adminString in pairs(adminList) do

For most programmers, this is going too far in terms of neatness, and I understand that. Most don’t make very long variables for the index and the value in a generic for loop, and that’s fine. Just be aware of this convention in case you need to make your code nicer in terms of for loops. On to the next line:

if string == newd00d.Name then

All we have to do here is replace the variable names we already declared:

if adminString == newPlayer.Name

That already looks better! On to the next line:

newd00d.Chatted:connect(adminchat)

First, lets replace the horrid variable newd00d with the newPlayer one that’s much better and easier to read:

newPlayer.Chatted:connect(adminchat)

The adminchat variable is obviously a function. We can follow that same convention for functions too. Even though adminchat is perfectly acceptable, ‘adminChat’ looks a tad bit better, because it easily distinguishes the two words. So lets replace that:

newPlayer.Chatted:connect(adminChat)

Now all we need are the three ends, and our final code is this:

local adminList = {}

game.Players.PlayerAdded:connect(function(newPlayer)

for adminIndex,adminString in pairs(adminList) do

if adminString == newPlayer.Name then

newPlayer.Chatted:connect(adminChat)

end

end

end)

That looks much nicer than the original code, doesn’t it? In the original code, the variables were all over the place, vague, and too long. This code is much easier to read, and you can clearly follow what is going on.

Another technique is to name variables with one word with a capital at the beginning. This is different than a constant variable, which is in all caps, and looks better than all lowercase. For example, instead of naming the player newPlayer, we could have named the variable Player, like this:

game.Players.PlayerAdded:connect(function(Player)

This looks better than player, and is easier to read to me. However, both are a standard programming style that different programmers like, so either is ok.

You may think all of this is a waste of time, and that’s normal. As you get more advanced and write more complex programs, you’ll want your code to be neat, otherwise you’ll get lost! If you know that feeling when you write code a certain way and look back at it later and ask yourself “Why did I write it like this?”, that’s because your programming style is getting better. Hopefully, these techniques will get you to stop asking yourself that.

Keep calm and code on!

– cardgamechampion