May-25-2020, 07:21 AM
I haven't really got time to look much at the code in detail, but a couple of quick things:
1. Commit messages: make sure they're useful - "commit" tells you nothing really about what that commit changes. I know you can look at the diff, but having a short summary lets you know at a glance. Commits should be small enough that you can describe a change in a short sentence. Why? A commit that's hard to describe is likely making lots of changes at once and that's bad because if you need to undo something, it won't be easy.
2. You don't really need to list the directory structure in the README. People can see the structure.
3. In your database code, you're using f-strings to parameterise your SQL statements. Don't do that, as it's vulnerable to SQL injection. Instead, you should be using parameter substitution placeholders. For SQLite, those are
1. Commit messages: make sure they're useful - "commit" tells you nothing really about what that commit changes. I know you can look at the diff, but having a short summary lets you know at a glance. Commits should be small enough that you can describe a change in a short sentence. Why? A commit that's hard to describe is likely making lots of changes at once and that's bad because if you need to undo something, it won't be easy.
2. You don't really need to list the directory structure in the README. People can see the structure.
3. In your database code, you're using f-strings to parameterise your SQL statements. Don't do that, as it's vulnerable to SQL injection. Instead, you should be using parameter substitution placeholders. For SQLite, those are
? characters (see the docs) and you'll be able to find out the ones for MySQL in their docs too.