Can I get some feedback / review on my code? - eviltoast

I started working through the 100 Days of Code course of Udemy last February, and I’m in the home stretch. I’m on the final lessons, which are really just prompts for projects. No hand holding, just a brief description of the goal. I recently finished a tkinter GUI program, the goal of which was to enable adding text watermarks.

I took a few liberties–mainly, I made it possible to layer a png on top of the background. It was a really fun project and quickly grew more complicated than I expected it to. I got some hands on experience with the Single Responsibility Principle, as I started off doing everything in my Layout class.

Eventually, I moved all the stuff that actually involved manipulating the Image objects to an ImageManager class. I feel like I could have gotten even more granular. That’s one thing I would love to get some feedback on. How would a more experienced programmer have architected this program?

Anyway, I guess this preamble is long enough. I’m going to leave a link to the repository here. I would have so much appreciation for anyone who took the time to look at the code, or even clone the repo and see if my instructions for getting it to run on your machine work.

Watermark GUI Repo

  • FizzyOrange@programming.dev
    2·
    5 months ago

    I can give you some basic Python set-up advice (which is hard-won because nobody tells you this stuff):

    1. Use pyproject.toml, not requirements.txt. It’s better and it’s the recommended way.
    2. Always use type annotations. I saw you used it a bit - well done! But just use it everywhere. Add declarations & type annotations for your class member variables. You’ll thank me later! Also prefer Pyright to Mypy; it is far far better (and the default for VSCode).
    3. I would recommend using Black to autoformat your code. It’s easily the best Python formatter. You can automate it using pre-commit.
    4. ALWAYS PUT MAIN IN A FUNCTION. You should not run any code at a global scope. Do it like this:
    def main():
  ...

if __name__ == "__main__":
    main()

    There are two reasons:

    1. Generally it’s good to keep variables to the smallest scope possible. Putting everything in a global scope will just mean people start using it in their functions, and then you have a mess.
    2. Any code you put in a global scope gets run when you import a module. Importing a module should not have any side effects.

    Other minor things:

    1. Path has a crazy/neat override of the / operator so you can do Path("foo") / "bar" / "baz.txt".
    2. Don’t use assert for stuff that the user might reasonably do (like not choosing a background image). assert is meant to be for things that you know are true. You are asserting them. Like “hey Python, this is definitely the case”.
    3. TK is an ancient shitty GUI toolkit. I would recommend QT instead (though it will probably be more pain to set up).