- cogs
-
Contains discord.py extensions, each with a Cog that implements some of the bot's functionality
- convert
-
One time use files for migrating data from earlier versions
- loopedfunctions
-
to be run locally, it runs some function periodically
- utils
-
Various functions that are used throughout the bot's code
- main.py
-
The entry point to the bot. Run it to start the bot up!
- data.db
-
Stores the data (as of current version)
- logs.txt
-
From the start of a logging project that never took off. Does not do anything as of now.
-
In general, we follow PEP 8, PEP 257, & PEP 484 guidelines, with some exceptions
-
PEP 8 -- Style Guide for Python Code
- Indentation: 4 spaces per indentation level
- Indentation Method: Prefer spaces
- Maximum Line Length: Haven't decided
- Line Breaks with Binary Operators: Break before binary
- Blank lines (Adapted):
- Separate imports, alongside top-level function and class definitions with three blank lines
- Separate method definitions inside a class are separated by two blank lines
- Use blank lines in functions and class methods, sparingly, to indicate logical sections
- Source File Encoding: UTF-8
- Imports (Adapted):
- Imports are always put at the top of the file, just after any module comments and docstrings, and before module globals and constants
- Imports should be grouped in the following order:
- Prefer absolute imports over relative imports
- Avoid wildcard imports (i.e.
from module import *)
1. Module level dunder imports
2. Standard library and package imports
3. Discord.py related imports
4. Local application/library specific imports - Module Level Dunder Names: Should be placed after the module docstring but before any import statements except
from __future__imports - String Quotes: Use single quotes
- Whitespace in Expressions and Statements
- When to Use Trailing Commas: Use when making a tuple of one element, or when a list of values, arguments or imported items is expected to be extended over time
- Comments: Keep them up-to-date, in complete sentences, easily understandable, and in English
- Block Comments: Starts with
#and a single space, seperate paragraphs inside a block comment with a line containing a single# - Inline Comments: Use sparingly
- Documentation Strings: Refer to PEP 257
- Block Comments: Starts with
- Naming Conventions (Adapted):
- Naming Styles:
- Functions, Variables and Class Methods:
lowercaseorlower_case_with_underscores - Classes:
CapitalizedWords - Module Level Dunders:
__double_leading_and_trailing_underscore__
- Functions, Variables and Class Methods:
- Names to Avoid: Don't use 'l', 'O', or 'I' as single character variable names
- Package and Module Names: Should have short, all-lowercase names, with underscores if it improves readability
- Function and Method Arguments:
- Always use
selffor the first argument to instance methods - Always use
clsfor the first argument to class methods.
- Always use
- Designing for Inheritance: Only needed class methods and instance variables (collectively 'attributes') should be public (If in doubt, choose non-public, can change later on if needed)
- Public and Internal Interfaces: Explicitly declare the names of public attributes in the public API using the
__all__attribute
- Naming Styles:
- Programming Recommendations
To migrate data from earlier versions, use the convert directory. Instructions can be found in instructions.txt there.
-
P&W API v3 (GraphQL)
-
discord.py
-
repl.it