Rules and Common Practices of Creating a Bot
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 bots with Pycord as well.
Most of these rules and common practices are only applicable for verified bots, but it's good to follow them nonetheless.
Rules
There are rules for creating bots, and most of these are required by Discord themselves, not us at Pycord. 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.
You don't need a lawyer or anyone special to write out a privacy policy for you, nor do you need it approved by some official entity. Simply writing out how you are going to use Discord user information neatly is all you need to do.
Providing a Terms of Service for your bot is optional, though usually a best practice. It tells users what they can and cannot do with your service, and makes it easier to settle disputes if someone disagrees 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's Developer Policy to make it easier on us. You can find Discord's Developer Policy here. This outlines what you can and cannot do with Discord'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 practices of creating a Discord bot with Pycord.
Bot Sharding
To any new or maybe even experienced bot developer, sharding a bot sounds beneficial once you hear about 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 on this page. Sharding is the process of taking your bot and breaking it up into small pieces, so it's easier to perform tasks. This is very useful for large bots, as it makes them faster and more reliable. Sharding is not a good practice for small bots.
Discord will notify you once it is time to shard your bot, and will eventually force you to do so.
At the very least, wait for one thousand servers to shard your bot. If you shard your bot while it's small, 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 bot is in more than 75 servers. It's generally a good idea to try to get your bot verified as soon as possible. We're talking at 76 servers soon. This is because Discord can be somewhat slow in terms of bot verification, so verifying as soon as possible gives them enough time to verify before your bot reaches 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 intents your bot doesn't use wastes both your time and Discord's time, as your privileged intent request will 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 explained elsewhere, 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 subclassing bots here
Your Bot's Token
Your bot is only able to be run for one reason: its token. If you followed the guide for creating your first bot, you should already know a bit about keeping 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 important to keep your token safe. To learn how to do so, read this part of the 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 Raspberry Pi's SD card that held your bot, you'll still have its precious user data. I have a small program for my 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 making almost any application. For a lot of developers, it's like saving your work. If you do this, all of your bot's code won't be lost if your computer spontaneously combusts, or you smash it to bits from anger. You can simply grab the backup computer that everyone has lying around, and you're back in 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 recognize it, 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 some
JSON 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 also
a 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 databases out 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 that works entirely on files. However, if for some reason you cannot read/write to and from a file, and you need to manage lots 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 is
synchronous 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 open source and is a complete drop-in replacement for any code with MySQL. You don't even need to change what package you're using!