Questions on style

[justsomeguy]

Hello

I was wanting to ask the forum on how you guys prefer to organize your code, especially on larger projects. I've posted a few of my projects on here and people had trouble getting them to work due to the way I structure my code. I want to make it as easy as possible to share across platforms, since I'm a Linux guy. 

• Do you prefer a large monolithic source file, or it broken up into libraries?
  
• If you use "libraries", do you keep them together with your original project, or do you separate them for reuse on other projects?
  
• Do you put the executable in the QB folder or in the source folder?
  
• How do you handle assets in regards to your file structure, so that it is easier to share?
  

Any other tips to help me better share my projects would be appreciated.

Thanks
justsomeguy

[bplus]

Hello

I was wanting to ask the forum on how you guys prefer to organize your code, especially on larger projects. I've posted a few of my projects on here and people had trouble getting them to work due to the way I structure my code. I want to make it as easy as possible to share across platforms, since I'm a Linux guy. 

• Do you prefer a large monolithic source file, or it broken up into libraries?
  
• If you use "libraries", do you keep them together with your original project, or do you separate them for reuse on other projects?
  
• Do you put the executable in the QB folder or in the source folder?
  
• How do you handle assets in regards to your file structure, so that it is easier to share?
  

Any other tips to help me better share my projects would be appreciated.

Thanks
justsomeguy

Hi @justsomeguy

I've got to check out your pool game, looks very good. Just from screenshot I see you offer an option of putting English on cue ball. I assume that IS what that white circle is for in lower left corner, I am sure.

About libraries, I don't have much of opinion, I use to use them in old QB4.5 work my own commonly used subs and functions but now with QB64, so many Subs and Functions more than 95% of code would go unused for projects. It's a pain to always have to include and explain with every post I make here at forum.

I would read what Terry has about libraries and coordinate with him about style issues from his Game Programming tut here: https://www.qb64tutorial.com/games
this work is most likely to get all newbies started on same page.

Now I would most definitely recommend storing all files related to project in a Folder of it's own for easy zip and extract sharing with he rest of us at forum just remove exe before zipping. I don't like sub-paths for assets but that is purely opinion if you have allot of files to go with project it makes sense to keep them organized in sub folders.

I have my Run's geared to save Exe's in same folder as source code the only exception might be for a library if QB64pe can find them without a bunch of monkey business to get paths correct and find the bi and bm.

[Kernelpanic]

If the whole thing isn't too big, I do it like this:


Otherwise there are more subfolders to keep track of things. My web pages were always like this (This is an old site for practice. One had to teach yourself everything.). I call that a line. The main folder is named like the page: Dino. All the necessary subfolders are there.

[bplus]

@justsomeguy just did quick test of your Pool Game, very nice and how you did Library was fine by me.

[justsomeguy]

I guess I always felt like the physics engine was its own separate project and the demos and games that used it were just clients of the the libraries that it contained. Yes, depending on the demo or game, large portions of the engine will not be used, and will be weeded out by the compiler. And that's reason for my weird file structure.

Thank you guys for your feedback! I will try to use your suggestions moving forward.

@bplus  Yes, that's the Pool Game I posted a while back. I never finished implementing English, It has left and right, but not top or bottom. I may one day return to it and make it a proper game.

[OldMoses]

I have used libraries, mostly to get the hang of doing it. However, I tend to use the libraries as a place to copy and paste those routines that I need for a larger project. That way the project is all inclusive and I can do modifications in one project without affecting others.

I keep the executables with the source folder as a rule. The exception would be when doing tests of code snippets, then I just do it in the QB64 folder. Once it works it gets copied and pasted to its ultimate destination.

I like putting assets in associated folders like 'images', 'sounds', 'scenario saves' and such like. If I do have inter-directory assets, then I resort to zip files for posting, but I try to avoid that. I'm not much for downloading zips; preferring to copy and paste member's code examples, and I assume others find it a bit of a pain too. A lot of the time, I try to have the code create what it needs when feasible.

[justsomeguy]

I appreciate the feedback. Since we are talking about style of large projects. I would like to share a tip that I use to keep track of sub and functions in large monolithic source files.

I like to put Dummy Subs in my code. Like this:

Code: (Select All)

'**********************************************************************************************

'  Main Loop

'**********************************************************************************************

SUB _______________MAIN_LOOP (): END SUB

So when I use the F2 key to look at the Subs and Functions I'l see this:



To me it makes it easier to navigate the larger code bases. I hope this helps. When I was playing with the QB64 source, it sure could have benefited from doing something like this.

[OldMoses]

That's a cool effect. It never occurred to me to use blank subs that way.

I have put development notes in large projects in a blank sub that contained remarks only.

SUB Comments
    'V. 1.0 enhancements, etc., etc.
    'V. 1.5 enhancements, etc., etc.
    'other project notes, jokes, doodles, copyright/license texts, etc.
END SUB 'Comments

One thing I do, as seen above, is to always reiterate the sub/function title as a comment after the END line. That helps me to tell at a glance what lies above my insertion point. I find it helpful if the sub is particularly long.

[TerryRitchie]

I appreciate the feedback. Since we are talking about style of large projects. I would like to share a tip that I use to keep track of sub and functions in large monolithic source files.

I like to put Dummy Subs in my code. Like this:

Code: (Select All)

'**********************************************************************************************

'  Main Loop

'**********************************************************************************************

SUB _______________MAIN_LOOP (): END SUB

So when I use the F2 key to look at the Subs and Functions I'l see this:



To me it makes it easier to navigate the larger code bases. I hope this helps. When I was playing with the QB64 source, it sure could have benefited from doing something like this.

I noticed that right away when digging through your code. I think I'm going to adopt this practice. Easier than naming related subs/functions with three letter indicators as I usually do, or creating multiple .BM files with related code that need to be included in other .BM files. When I write a library I always strive for one .BM file and one .BI file if possible.

[Ultraman]

This is in no way me casting a stone at justsomeguy, but I am definitely not a fan of the empty SUB idea. Code that exists only to break up other code visually just doesn't seem like a good idea. Besides, I prefer the kind of subs that crush under pressure.