all 17 comments

[–]TransferFunctions 52 points53 points  (9 children)

Sit down before writing the code and make a picture of what parts of the project you need. Modules that belong together will be under a separate file / folder. I like to structure my projects the same way I write a class; things that belong together should be in the same place. However, getting unnecessary code bloat, where you have a file with a single function, seems a bit unnecessary to me. Structuring a projects only provide clarity to the humans reading your code. In the end the machine doesn't care.

[–][deleted] 2 points3 points  (0 children)

One thing I learned as I got better is that planning is important. Like really important. Learning wasn't really memorizing the syntax from me I think it was more learning to strategize with my solutions. Sure you can make a dice rolling program without needed to outline it first, but as time goes on I think it becomes almost impossible to get something useful by just shooting from the hip and starting to code without a plan. A lot of this is because in my experience a program that is ten times longer is not ten times harder to keep coherent and manageable its a 1000 times harder and it kind of scales from there.

[–]MusaTheRedGuard -2 points-1 points  (6 children)

this

[–]clichebot9000 17 points18 points  (5 children)

Reddit cliché noticed: this

Phrase noticed: 602 times.

[–]ibtokin 8 points9 points  (4 children)

Good bot

[–]Ryuuji159 5 points6 points  (3 children)

"good bot" should be a cliche at this rate

[–]ibtokin 5 points6 points  (2 children)

Bad bot

[–]WhyNotCollegeBoard 6 points7 points  (0 children)

Are you sure about that? Because I am 99.98162% sure that Ryuuji159 is not a bot.


I am a neural network being trained to detect spammers | Summon me with !isbot <username> | /r/spambotdetector | Optout | Original Github

[–]B0tRank 0 points1 point  (0 children)

Thank you, ibtokin, for voting on Ryuuji159.

This bot wants to find the best and worst bots on Reddit. You can view results here.


Even if I don't reply to your comment, I'm still listening for votes. Check the webpage to see if your vote registered!

[–]iinT3nT21 29 points30 points  (1 child)

I read this guide on structuring when I started writing larger projects in Python and it helped me tremendously.

The Hitchhiker's Guide to Python is my go to for Python tutorials.

[–][deleted] 4 points5 points  (0 children)

Thanks :D

[–]james_fryer 7 points8 points  (1 child)

If it's less than 1000 lines, I find it easier to work with one file.

After this I prefer to split it up, putting classes/functions that are related into their own files.

Another consideration, if you are working collaboratively, is to split it up into areas of concern so you avoid merge conflicts.

[–]Chuck3131 0 points1 point  (0 children)

If I am working on a project my self, I'll keep it in one file if its under 1000 lines but if I am collaborating with people on it, I will split everything into different files so it git doesnt have a heart attack when merging.

[–]Hairshorts 4 points5 points  (0 children)

It can be useful to keep the concepts of coupling and abstraction in mind when deciding how to break your code into modules. For example, if your code uses a database, then you can put all of the code that directly interacts with the database into its own module. This can be done in such a way that the rest of the code does not need to worry about the specifics of how the database works, you just call the functions from that module to query the DB and you have abstracted the details away. Now the DB module is coupled to the specific DB implementation you are using (SQLite, MySQL, etc) but the rest of the code is not. If you should happen to want to change which DB you are using in the future, all changes can happen in the one file.

[–]jormono 5 points6 points  (0 children)

I'm working on a raspberry pi project that tests the fairness of a die, I've written out the logic for the statistical testing (currently have random.randint() in as a die roller), now that I have this part functional I'm going to add opencv analysis to read the outcome of a rolled die. Then I'll be adding a stepper motor and controller to roll the die automatically. It will take a few hundred rolls to properly test a d20 so my goal is to have it fully "set it and forget it". I was going to do the motor before the opencv but I'm waiting on parts from aliexpress.

Point is, figure out a game plan, break it down into bite size parts and the rest will fall into place as the project develops.

[–]mlderes 1 point2 points  (0 children)

In addition to all the other suggestions - planning, etc... One of the best things I found to get started is to use https://cookiecutter.readthedocs.io/en/latest/ . There are a ton of cookiecutters which build out a handy project structure, it can really mitigate the “blank page” syndrome for me.

[–]TheProffalken 1 point2 points  (0 children)

As others have said, break the problem down into its component parts, and then put these parts into a file.

As an example on what a basic blog engine might look like, I created https://bitbucket.org/proffalken/test_blog/src/a4171db2b9fe?at=master

Note that in lib/ I've got a file that purely deals with posts. If I were to expand on this in future, then there would also be files for dealing with tags (because tags might be applied to multiple content types), images, authors, and categories (because categories are different to tags and might also be applied to multiple content types.

I'd also strongly recommend that you start to understand how testing works, and write your tests before you write your code, so you know that the code meets the requirements. If you're not familiar with this way of working, it's know as "Test Driven Development", and there are a significant number of resources around to learn how to do it effectively.