I can write small scripts but have no idea how to structure a full project. Where do I start?
Posted by SpeckiLP@reddit | learnprogramming | View on Reddit | 13 comments
I've been learning Python for a few months. I can solve coding challenges and write scripts that do one thing, like scrape a website or rename files in a folder. But when I try to build something larger, like a small game or a to-do app with a GUI, I freeze up.
I don't know where to put my functions. I don't know how many files I should have or how to make them talk to each other. I end up with one massive script that becomes impossible to debug.
I've looked at open source projects but they feel overwhelming. Everyone talks about design patterns and separation of concerns but I'm still at the stage where I just want my code to not break when I add a new feature.
What's a practical first step for learning project structure? Should I just copy the folder layout from a similar small project and work backwards? Or is there a minimal example somewhere that shows how to organize, say, a 500-line program before adding complexity?
huuaaang@reddit
Look at other projects. IF you're writing a game, you're probably using a game engine which will have it's own project structure gives to you.
Unfortunately Python is kind of bad place to start in this regard because there are a LOT of Python programmers who are in your position who don't know how to structure of project. So it's easy to learn bad habits from other people who were, themselves, just kind of guessing. Python is used a lot by "non-programmers."
I would say start with an opinionated framework that gives you the structure. For me it was Ruby on Rails many many years ago. That was my personal step up from writing scripts to writing full projects with tests, database migrations, models, controllers, etc.
Formal_Wolverine_674@reddit
Honestly most people learn project structure by first suffering through a giant unreadable script and slowly splitting it apart as the pain grows
Express-Channel-1686@reddit
think in nouns first. what are the things in your app (User, Order, Note...). one folder per noun, dump related code in there. structure clicks when you stop thinking in 'scripts' and start thinking in 'systems with parts'
bestjakeisbest@reddit
Start with a small project, maybe implement a card game in a program, maybe make a tool that will help you later.
Educational-Paper-75@reddit
Single file is always easiest. Put the functions wherever you want. Multiple files in same folder is next; import by file name without the extension (.py). Put related functions and data they operate on in same file. Simplest rule of thumb is to put classes in their own files. More difficult structure like split across different folders never used them.
NotA-eye@reddit
Honestly, don’t jump into “design patterns” yet. That stuff makes way more sense after you’ve struggled through a few messy projects 😅
What helped me was literally copying the structure of small GitHub projects and tweaking them.
Also, stop aiming for the “perfect structure.” Even real projects get reorganized constantly.
For a small app, just start with:
– one file for main app logic
– one for helpers/utils
– one for UI/data/etc depending on project
That alone already feels way cleaner than a giant script.
You learn structure by refactoring over time, not by magically knowing it upfront.
InsanityOnAMachine@reddit
*sigh* there are a few different ways to go about it.
Way one, is, if you want the project *done*, and this will be true for any large project, it won't be perfect. If you want a working thing, just start adding code upon code upon code. You want a thing? patch it on and move on. A true chef of spaghetti code.
This will result in something that A: Works \~80% good, and B: is hard to maintain. There's a saying, "Nobody cares how good it doesn't work"; in the "real world", whatever that means, having something that works, despite the *don't look at the code!*, is what impresses people.
Way 2 is to obsessively plan out everything beforehand; as well as can be predicted. Do valuable research, pick your libraries, make a file structure, empty module files, etcetera et cetera. Then code interfaces between these modules, and so on and so forth. Problem is you really only get to test it once all the pieces are in place. Benefit is everything is real neat and tidy.
Way 3 (what I do) is sort of worse-sort-of-better; for my largest project, I hacked a prototype together super fast, all sloppy, that worked. Then I made a new folder and remade the thing a bit better (all in one file still). No pressure, as I'd already made the thing working, I could, in a pinch, just use my prototype. Then, over time, I moved functions around, made new files, et cetera, etc. It still wasn't the easiest to maintain, but it worked (\~99% well).
There's also something called Tracer bullets, described in the amazing book The Pragmatic Programmer. Basically (as I recall) you make a working, no-frills, straight path through your project; say you imagine the user clicking here, opening the menu, selecting this thing and adding a task.
You make *just* the code to support that exact path of decisions, and nothing else. All of the problems you come across trying to make this one path will be super helpful in getting a feel for the project. In the end, you keep this code; it's fully working code, and you just add onto it the rest of the functionality, hopefully pretty frictionless 'cause you already have the basic menu code, button code, frameworks, etc.
Lost_Frosting7106@reddit
i can understand why large projects are overwhelming, keep in mind that most of them start small and they grow with time
depending on the goal you could use a framework for example Django if you want to build web apps
my usual approach is to think what i need for my project, start with the minimum and add tools/modules as you go
start small or break the large project to many small tasks
for example if building a software business you'd start with a landing page, then add a dashboard, then add authentication, then add API for dashboard, then maybe redesign the landing page
work in smaller iterations
yesimcrazyboy@reddit
Start by looking at the structure of one small project you admire — not a huge open source repo, just something with 3-5 files. Copy that layout and fill it with your own code.
The key mental shift: each file should do one thing. If you have a to-do app, you might have one file for the data (storing/loading todos), one for the logic (add/delete/filter), and one for the UI. When you're unsure where something goes, ask "if I delete this file, what breaks?" — that tells you what belongs there.
Don't worry about design patterns yet. Just go from 1 file to 3 files. That's the real first step.
Helpful_Ad_9447@reddit
I feel this. When I moved from designing logos to full brand guides I froze the same way. Maybe try mapping your project on paper first. Draw boxes for each file or function and arrows showing how they talk to each other. Then fill in the code one box at a time. Helped me stop dumping everything into one giant mess.
SpeakMillenial@reddit
I think what you might be missing is that every language is a separate tool with its own purpose. Knowing Python doesn't mean you can suddenly use it out of the box to do anything. Just like you can't use a hammer to fix a window. There are python libraries to help you build a GUI but I don't think they would be the standard
OnyXerO@reddit
"Should I just copy the folder layout from a similar small project and work backwards?" - yes.
How we ensure adding functionality to our projects doesn't break any existing functionality is with things like design patterns and separation of concerns.
Find a small project that does something you can understand and then read it until you start to see the relationships between the modules. Once you see how it's broken up you can start to understand why it's broken up how it is. Where the boundaries are drawn and so on.
Then pick larger and larger projects until you understand the patterns.
So much of this is pattern recognition. Read, practice, repeat.
MeLittleThing@reddit
This is where you start. Use your favorite search engine to find the answer of this question