+- QB64 Phoenix Edition (https://staging.qb64phoenix.com)
+-- Forum: Chatting and Socializing (https://staging.qb64phoenix.com/forumdisplay.php?fid=11)
+--- Forum: General Discussion (https://staging.qb64phoenix.com/forumdisplay.php?fid=2)
+--- Thread: Questions on style (/showthread.php?tid=1785)
RE: Questions on style - justsomeguy - 06-26-2023
Quote:This is in no way me casting a stone at justsomeguyNo worries, differing opinions can lead to a better solution.
Quote:Code that exists only to break up other code visually just doesn't seem like a good idea.If you are worried about empty sub making it into the executable, the compiler should cull those out while compiling, and it should never make it into the executable. Someone can correct me if I'm wrong. Regardless its vestigial code.
The reason for me to do it this way, came out of necessity due to the limitations of then IDE and having a large code base. If the IDE could handle multiple tabs, this would of never came about. However, its the limitations that programming in QB64 fun.
Thanks for you feedback!
RE: Questions on style - Ultraman - 06-26-2023
Oooo.... speaking of tabs, you can install a software (on Windows) called Stardock Groups (I think) that allows you to make tabbed windows of any program. Of course, that doesn't really solve your problem but it does make it nice and organized. But I didn't know that the empty subs wouldn't make it to the final exe. That's cool if that is true. I didn't think the compiler was that smart.
RE: Questions on style - Ultraman - 06-26-2023
But I really wish we had code folding in our IDE. Then again, you could also just do it with the Visual Studio Code extension that Grymmjack wrote a tutorial for. It has lots of cool features. I haven't ever been able to take much advantage of these features but there are tons of them.
RE: Questions on style - bplus - 06-26-2023
(06-26-2023, 11:32 AM)Ultraman Wrote: 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.
In really HUGE programs your coding development can be crushed just by the amount of subs and functions included!
I remember having to make commented line number maps at the start of my GW Basic programs just to navigate a couple hundred Lines Of Code, LOC.
justsomeguy just offers us an idea of how to deal with that crushing amount of Subs and Functions, you don't have to use it.
A friend of mine use to say, allot!, "You don't have to like it." Maybe because I was offering too many negative opinions ;-))
RE: Questions on style - madscijr - 06-27-2023
(06-25-2023, 06:18 AM)justsomeguy Wrote: HelloIn general: The simpler the better!!
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
Disclaimer: I don't expect my own taste to reflect the majority or opinions or work for everyone, but just speaking for myself...
For QB64 games: I do find it easiest to have everything in one monolithic source file, and beyond that, minimal resource files (e.g. I prefer to define sprite sheets and tile sets as text strings that can be visually edited). I just personally find it easier to only have to worry about a single file, and also I like "type-in" style programs like they used to have in computer magazines in the '80s!
For VBA: I prefer separating out different functionality into different modules (e.g. string functions, date functions, etc.)
I haven't worked with large projects in a while, but always found the bigger an application got, the bigger the headaches. I especially loathed working with solutions in Visual Studio that used multiple projects and required you to remember & manage complicated settings and source control stuff, that quickly eats up my mental processing cycles and patience before I even get to writing actual code. Keep it simple, silly!
It amazes me that most software developers are not only able to handle these complicated tool chains and code organization, they prefer & thrive in it! They must have an extra lobe or three in their brains that I'm missing, LoL! :-D
I think one very helpful application of ChatGPT or AI in the future will be to allow people with very different styles and brains to view code and work on programs in a way that suits their own style...
RE: Questions on style - madscijr - 06-27-2023
(06-26-2023, 12:17 PM)Ultraman Wrote: Oooo.... speaking of tabs, you can install a software (on Windows) called Stardock Groups (I think) that allows you to make tabbed windows of any program. Of course, that doesn't really solve your problem but it does make it nice and organized. But I didn't know that the empty subs wouldn't make it to the final exe. That's cool if that is true. I didn't think the compiler was that smart.That Stardock Groups sounds interesting - thanks for sharing, I'll look that up!
RE: Questions on style - TerryRitchie - 06-27-2023
(06-27-2023, 02:49 PM)madscijr Wrote: It amazes me that most software developers are not only able to handle these complicated tool chains and code organization, they prefer & thrive in it! They must have an extra lobe or three in their brains that I'm missing, LoL! :-DI'm right there with you. I get confused very quickly when tool chains start getting even a few levels deep. I equate it to me getting old and not really having to worry too much about organization back in the day because project sizes were nothing compared to today's. That's probably why I prefer to code in QB64. It's fun and easy to whip up something cool in a minimal amount of time.
I also try to keep all main code in one file and libraries in a separate file (one .BI and one .BM), or even a few if I'm loading multiple libraries. I also like to keep assets (sounds, graphics, etc..) within the same working directory as the code and avoid using subdirectories as much as possible.
Just my style, YMMV.
RE: Questions on style - SMcNeill - 06-27-2023
When it comes to style, as you guys have probably noticed over the years, I tend to be the sort that relies heavily on writing and using code for library usage. The very idea of writing a 100,000 line program begins to boggle my mind, even before I ever sit down and write the first line of code. Trying to navigate through such a mess would just cause me to completely lose focus and not be able to work on anything. "Now, where was this variable at? Oh yeah, it was 14 pages up somewhere in the code..." *Scroll... Scroll... scroll...* "Now, WTH was I looking for, to change again??"
The only way I can organize my stuff is to break it down into working modules. I tend to have the main module, along with a keyboard handling module, and an image handling module, and a mouse module, and a printout/display module, and maybe a few more... -- and each of these are separate, independent libraries which I just $INCLUDE into the main source. The vey idea of merging all those modules into just one long BAS code somehow makes me shiver down deep in my soul. I know me -- I honestly wouldn't be able to function or work half as well with such a style.
I *NEED* things to be organized into those modules, but almost NEVER into submodules. Just as the idea behind "one superlong file" disturbs my personal flow, the concept of "let's put a module inside a module inside a module inside a module inside a module..." just makes me want to puke. Normally when I code, I'll have 2 or 3 IDE windows/tabs open to code in. One might have the main module in it that I'm working on, while another holds the module that I need to adjust or expand upon at the time, with the third being to just test immediate things to either refresh my memory or look for bugs/issues which something might cause. To try and have the main module, submodule, and then other sub-submodules all open at the same time... Once again, I'd just get lost and wouldn't be productive at all.
So my personal style tends to always be:
1) Write modular code for library use.
2) Have a main module and include my submodule/library files.
3) Try to never go beyond a single depth in my library usage. (Note that in some **extreme** cases, I might break this rule -- such as if I merge things into an 'Input Library' which then has a submodule for keyboard input, then a submodule virtual keyboard, then a mouse input submodule, then a joystick submodule... In the main module, things may consolidate down to just a single line for 'Input Library', but all that library does is include all those independent libraries which I can still open/edit one at a time as needed.)
RE: Questions on style - SMcNeill - 06-27-2023
As for the EXE question, I *always* select the Output EXE To Source option with the compiler. My file structure is always assumed to be in relation to my BAS file, and I tend to direct everything from there. "./" <-- this little home path tends to set the stage for where everything is located, and then I adjust files/resource from there.
image = _LoadImage("./images/whatever.png",32)
font = _LoadFont("./fonts/whatever.ttf",16,"monospace")
And so on.
RE: Questions on style - madscijr - 06-27-2023
(06-27-2023, 04:18 PM)TerryRitchie Wrote:I 100% agree on the subdirectories - keeping libraries in a separate file is reasonable, but for me the less folders and dependencies, the easier it is to work with. It would just be easier if QB64/QB64PE had a tabbed editor to make it easier to work with multiple files.(06-27-2023, 02:49 PM)madscijr Wrote: It amazes me that most software developers are not only able to handle these complicated tool chains and code organization, they prefer & thrive in it! They must have an extra lobe or three in their brains that I'm missing, LoL! :-DI'm right there with you. I get confused very quickly when tool chains start getting even a few levels deep. I equate it to me getting old and not really having to worry too much about organization back in the day because project sizes were nothing compared to today's. That's probably why I prefer to code in QB64. It's fun and easy to whip up something cool in a minimal amount of time.
I also try to keep all main code in one file and libraries in a separate file (one .BI and one .BM), or even a few if I'm loading multiple libraries. I also like to keep assets (sounds, graphics, etc..) within the same working directory as the code and avoid using subdirectories as much as possible.
Just my style, YMMV.
I forgot to mention that although I prefer one monolithic file in QB64, I do try to keep my code organized by function (general-use, graphics definitions, tile routines, etc.) Having collapsible sections would be nice for this approach.
If the QB64/PE editor supported having multiple tabs open at once, I might start separating routines out into different BI/BM files, but wouldn't want things to get too complex (e.g. subdirectories). I know you can configure Notepad++ and other editors that do support tabs to work with QB64 & QB64PE, but I haven't found one that supports the realtime syntax checking.
On the subject of multi-file programs, does QB64PE have that feature where if 2 or more files in a project include the same file, it's smart enough to ignore the duplicate? I can't recall if I saw this for QB64, QB64PE or some other language (maybe Python?)