How to modularize code

[StillLearning]

To anybody who can point me to a tutorial on how to create multiple files (modules) that you link together and become a freebasic program.
I have separate subs and functions and global variables with global structures working as 1 BIG file but would link to know what to do to have them as separate modules in separate files.

Thank for your help.

[TJF]

Just identify global and module level variables and declare them properly.

I use CMake to manage the build process. Find a multi module example at

https://github.com/dtjf/fbdoc

[fxm]

See also in the Programmer's Guide:
- Making Binaries / Static Libraries
- Making Binaries / Shared Libraries (DLLs)

[fxm]

T I have separate subs and functions and global variables with global structures working as 1 BIG file but would link to know what to do to have them as separate modules in separate files.

Already, it is not good to use global variables in a module to pass them implicitly to internal procedures, instead of defining parameters and passing them as arguments, but even more so to make them common to another module.

[RockTheSchock]

viewtopic.php?f=2&t=22372&p=196236&hili ... de#p196236

[TJF]

Already, it is not good to use global variables in a module to pass them implicitly to internal procedures, instead of defining parameters and passing them as arguments, but even more so to make them common to another module.

In order to avoid complex parameter lists, it's a proper technique to use at module level global (but not common) variables.

[fxm]

The many variables can be grouped together in structure(s) such as UDT(s). Therefore, only UDT instance(s) is(are) passed as parameter(s).

[TJF]

The many variables can be grouped together in structure(s) such as UDT(s). Therefore, only UDT instance(s) is(are) passed as parameter(s).

When in a module each and every SUB/FUNCTION needs the same UDT, it does not make sense to pass it as a parameter. And: when passing as parameter, the UDT must be COMMON in order to call SUBs/FUNCTIONs from other modules.

Example: a driver module needs some hardware parameters. But that low level data shouldn't show up in other modules using that driver.

[speedfixer]

The program is yours: you do as you wish.

Globals are basically out of fashion. Just like learning BASIC will produce a crippled programmer or GOTOs should be banned.
Or the many-times-sold idea that a multicore processor is required for threads.

If any of the above were true, we would not have any of the cpu chips, languages, or OSs that we have today.

Learning to reduce the amount of shared variables teaches many things. The best lesson is probably encapsulation. Past that, it really is a fashion choice.

At its most basic:
For LARGE programs - globals will punish you.
For small programs, they will keep your code small, and you can write fast.

As always, moderation is the key.

I will get a lot of pushback about this, but there are some here that think they are the Code Police or UBER teachers. First clue is the huge number of posts from these guys. Most are genuine efforts to help, but sometimes a few believe you shouldn't be taught anything if the teacher can't teach you RIGHT. But at one time most teachers taught that the earth was flat and had detractors killed for disagreeing. I guess I should run and hide. (Notice: GOTO exists, COMMON SHARED exists. Follow the language rules, not the fashion rules. Next month, there will be a new fashion.)

First, learn the difference.
Then, find YOUR style.

Don't get sidetracked on topics not relating to your question/problem (like paying too much attention to this reply of mine.)
Learning to create multiple files to modularize as YOU wish is the task, not code fashion.

First:

An included file looks just like it was inside the body of your main code. That simple. The rules don't change: something has to be declared before it can be used. There are other rules of the language.

If you want to precompile any of the modules, then you have to learn about how to link them. The data must move between modules some way.
They can be passed one way or another, or shared.

The references made by the others, the keyword pages and other links in the Programmers pages - Static and DLL - should be enough.

The rules still don't change: something has to be declared before it can be used. This is the tricky part of modularizing.
You can't simply later throw them together without STILL following the rules of the language.

Just remember:
For LARGE programs - globals will punish you. First reason: you will soon need the list of globals on your big-screen TV while programming to keep track of them. This is why programming TEAMS have the rule: no globals.

You are not a team. But as the program grows, the need for globals should diminish. Disappear: that's up to you.

My method: a global thrown in to fix/patch/diagnose a problem, then see if that can be improved.

david

[jj2007]

30+ years of experience with Basic and Assembly:

- avoid global variables but don't make a religion out of that
- every if ... else ... endif has GOTOs under the hood
- arrays are global, and rightly so
- "projects" of a thousand lines split into ten modules are ridiculous
- as long as my 22klines editor source loads and saves in one second, and compiles in 1.5 seconds, it will remain one monolithic block.

This might change if somebody forced me to work in a team, but that is not the case ;-)

[badidea]

...
- arrays are global, and rightly so
...

?, That does not sound right.

Code: Select all

sub test123()
    dim as ubyte array1(0 to 10)
end sub
print array1(0)

[jj2007]

...
- arrays are global, and rightly so
...

?, That does not sound right.

Code: Select all

sub test123()
    dim as ubyte array1(0 to 10)
end sub
print array1(0)

Let the argument begin: It's a small block of memory on the stack. In Assembly that would be LOCAL array1[11]:BYTE, and it wouldn't cost more than 1 cycle to allocate and free this block of memory. I wouldn't call that an array. A real array has a bunch of bells and whistles attached to it, and that costs - one reason to use it sparingly, and global, so that all subs and functions can access it directly.

[badidea]

Wikipedia: An array is a systematic arrangement of similar objects, usually in rows and columns.
No need for bells and whistles, nor assembly.

[jj2007]

Even my modest implementation of arrays in MasmBasic (i.e. purest Assembly) has over 30 bells and whistles. To name a few: Insert/Delete element, sort the array, search, Recall, ... but of course, you are right, technically speaking getting a pointer to an area of memory with HeapAlloc(..) constitutes creating an "array". Same for subtracting 1000 bytes from the stack pointer: you can certainly call that an "array".

[speedfixer]

Let's NOT let the argument begin.

This is Programming Beginners -- about FreeBASIC, not assembly.

The objective is to help someone with FB code, not sell that you *may* know something about some other language.
If that other language is that much better, go there and stay there.