How I name files and modules in my Flask Apps. Always learning!
Hey there! Welcome to my blog where I post about my journey as a self-taught developer. You can find my GitHub by clicking HERE.
I don’t like to read, I actually have trouble staying focused. But I made an exception and took a break from video tutorials, and udemy.com!
This is what I came across.
There is a book called “Serious Python — Black belt advice on deployment, scalability, testing, and more”. The book has quite a few tools and helpful resources inside and I must say, I am enjoying it! Written by “Julien Danjou”.
Something that came to my attention which was easier to implement in my own apps over other more difficult content in this book, is how to name your files and modules.
“Organize your code based on features, not types.”
Yes, the above excerpt is taken from page 8 of Chapter 1 of “Serious Python”! But I spent a good hour going through my codebase for work and checking on my naming conventions and project structure. It was well worth it, because it is not just my codebase. It may belong to someone else one day, and I am only hurting future developers if the codebase I maintain is messy and hard to navigate!
Let’s take a look at a quick example of a feature, and a type.
TYPE:
Say we have several functions that are not related to one another. We want to modularize our code, however, if we stick a bunch of unrelated functions in a functions.py file, you can imagine how convoluted this may be to a new dev on the scene. Even if we comment and provide instruction within the file or README.md? Still not a recommended approach, which I must agree with.
This functions.py generic file, would be considered a “TYPE”.
FEATURES:
Now let’s look at a feature based approach. Please bare with me as this will be related to insurance, since that is the industry I program in at the moment!
What functions do I have in my current project. Well, I have functions that do calculations on premiums, functions related to e-commerce checkouts, maybe a few functions related to renewals and buying a new policy from a clients perspective. And then I have blueprints. I keep my functions separate in a /helpers directory
This allows me to import and reuse functions for date manipulation, rate manipulation, generating PDF’s, even some payment gateway functionality as well.
Screenshot of commented directory tree below!
This is a small example of how I have different features / products / services organized in a way which is easy to find. Most of the time, I’ve noticed developers have trouble deciding where they should put their code. Features over types solves this dilemma.
My helpers directory houses functions, yes. And logic pertaining to specific blueprints such as authorize_net.py for the payment gateway. Why did I do this?
Because authorize_net.py has functions that relate to checking out at the end of the buying process, and functions in that file all take parameters based off of which file it is being imported in.
I can reuse functions in authorize_net.py for routes/admin/renewals.py for when an admin renews a policy.
OR
I can reuse functions in authorize_net.py for routes/users/renewals.py for when a user or client renews their own policy.
Not repeating oneself in a large route can be very beneficial. Less code, less typing, and easier to navigate to one source of truth for a specific feature.
As always, I only learn by others so your input is welcome. If you have a more efficient way to structure your codebases in Flask, I would be delighted to read and grow as a developer.
Happy Coding!
