Rules and Common Practices | Pycord Guide (2024)

When creating almost anything, there's always a certain set of rules to follow or common practices,such as PEP8 for Python. This applies to creating botswith Pycord as well.

There are rules for creating bots, and most of these are required by Discord themselves, not us atPycord. Not following these rules may get your bot denied for verification.

Terms of Service and Privacy Policy​

Starting at some point in time, Discord has made providing a privacy policy with your bot a requirement.This is so that Discord knows exactly what you are doing with its users' data.

Providing a Terms of Service for your bot is optional, though usually a best practice. It tells userswhat they can and cannot do with your service, and makes it easier to settle disputes if someonedisagrees with you.

Read more in Discord's official Legal Docs.

Developer Policy​

We could list almost every rule about using Discord's API here. Or we could simply link Discord'sDeveloper Policy to make it easier on us. You can find Discord's Developer Policyhere. This outlines what you can and cannot do withDiscord's Developer API. And, don't worry, it's completely readable and understandable.

Best Practices​

Now, here's something we can't simply link an article for. We're going to discuss the best practicesof creating a Discord bot with Pycord.

Bot Sharding​

To any new or maybe even experienced bot developer, sharding a bot sounds beneficial once you hearabout it. I'm here to tell you that it isn't a good idea to shard your bot.

Wait a minute, why would it be an option if it wasn't a good idea? It's simple. I lied. Sort of.I'm not going to go into the details of sharding a bot, so you can read about it onthis page. Sharding is the process of taking your botand breaking it up into small pieces, so it's easier to perform tasks. This is very useful for largebots, as it makes them faster and more reliable. Sharding is not a good practice for small bots.

At the very least, wait for one thousand servers to shard your bot. If you shard your bot while it'ssmall, you'll just be wasting resources and possibly making your bot slower.

Verification​

Verifying your Discord bot is something every developer would like to achieve. It shows that your botis in more than 75 servers. It's generally a good idea to try to get your bot verified as soon aspossible. We're talking at 76 servers soon. This is because Discord can be somewhat slow in terms ofbot verification, so verifying as soon as possible gives them enough time to verify before your botreaches the 100 server cap. If a bot is not verified, it cannot grow beyond 100 servers.

It's also a good idea to only apply for the privileged intents that you need. Applying for intentsyour bot doesn't use wastes both your time and Discord's time, as your privileged intent requestwill be denied simply because you applied for an intent you didn't need.

Subclassing​

While it may take some time, subclassing a bot is very worth it. Once again, this was explainedelsewhere, so I won't go into the details, but I felt it fit here, so I put it here.

Subclassing a bot makes it more flexible and allows it to do a lot more. Read more about subclassingbots here

Your Bot's Token​

Your bot is only able to be run for one reason: its token. If you followed theguide for creating your first bot, you should already know a bit aboutkeeping that token safe. That's exactly what you want to do.

Sharing your token is never good. If someone evil gets a hold of your token, they can do terrible things,such as making your bot leave all of its servers, spamming all the members the bot has contact with,and even manipulating the servers the bot is in, if given the permissions. That's why it's very importantto keep your token safe. To learn how to do so, read this part ofthe Creating Your First Bot guide.

Backups​

You always want to back up your bot's data. This includes both its code and its databases. This way,if something tragic happens, such as your host failing a data migration or you breaking your RaspberryPi's SD card that held your bot, you'll still have its precious user data. I have a small program formy bot that uploads its databases to a remote GitHub repository periodically to not lose any data.It may be smarter to find a bit more of a reliable way to do so, though.

Public or private, having a local Git repository connected to a remote one is a good idea for makingalmost any application. For a lot of developers, it's like saving your work. If you do this, all ofyour bot's code won't be lost if your computer spontaneously combusts, or you smash it to bits fromanger. You can simply grab the backup computer that everyone has lying around, and you're backin business.

Organization and Cleanliness​

It is extremely important to have organized code. This includes commands, objects, functions,and classes. If you don't have organized code, it will get progressively harder for you to recognizeit, and others won't be able to decipher it.

Make sure you utilize indents and spaces, as these are very important in making your code readable.

class MyClass:
 async def add(self,num1,num2):
 return num1+num2
 async def sub(self,num1,num2):
 return num1-num2

class MyClass:
 async def add(self, num1, num2):
 return num1 + num2

 async def sub(self, num1, num2):
 return num1 - num2

See the difference? Now, which one looks more readable? Hopefully, you answered the second example.Python's PEP8 is a PEP (Python Enhancement Proposal)style guide for Python. It is the style guide that is used by most Python developers and programmers,providing a universal way to write and read code.

Databases​

As your bot grows, you'll inevitably have to store data for your bot. Now, most people would probably just load up someJSON file on boot into a dict, modify it in memory then write to the file. However, JSON files aren't the solution.When you write to a JSON file, it rewrites the entire file instead of just rewriting the section that changed. It's alsoa configuration file format, not a storage file format.

Instead of using a JSON file or some other related format, you should instead use a database. There are many databasesout there, like MongoDB, SQLite, and PostgreSQL to name a few.

All of these databases I named do the job well, and which one you use depends on what features you want out of a database.

MongoDB​

MongoDB is a JSON-like format and if you already use JSON files, it shouldn't be too hard to migrate over to.

SQLite​

SQLite is based on SQL, a common relational data model. It's a lightweight, easy-to-use, portable database solution thatworks entirely on files. However, if for some reason you cannot read/write to and from a file, and you need to managelots of data, SQLite might not be for you.

While SQLite is a part of the Python Standard Library as the sqlite3 package, we recommend not using it as it issynchronous and blocking. You should use an asynchronous alternative, such as aiosqlite.

PostgreSQL​

PostgreSQL is also based on SQL, but it also has more features than SQLite. It's compliant with the SQL standard,open-source, and extensible. However, it's not that fast or simple compared to SQLite.

MariaDB​

MariaDB is also based on SQL and is a fork of the MySQL project. It's compliant with the SQL standard, it's also opensource and is a complete drop-in replacement for any code with MySQL. You don't even need to change what package you'reusing!