Sub-Routines & Modules (Private vs Public)

Ok, I'm really getting into this forum. Teach me baby.

Why do you have to use subs? Are they optional? What is the concept behind using a module or not using one. How about option explicit?

VB Gurus - On your mark, get set, Answer ---

Modules = Separate files that hold code.

The most practical use for them is that you can use the same module in more than one program.

If you write a bunch of code that may be useful in more than one program you write, you want it in a module so you don't have to copy/paste/create unneccesary files.

Option Explicit forces you do declare every variable you use.

This can make your code more professional, and use up less memory, because if you use a variable that isn't declared, it's automatically declared as type VARIANT which is a waste of space if it's only going to hold an integer, etc...

Hi Sal.

Glad to see someone out there who's so enthusiastic about this stuff. :) I'll try to answer some of your questions, but like everything in life... take the stuff you can use and forget the garbage. Hopefully, this will not be the latter of the two.

Now for your questions...

1. Why do you have to use subs? Are they optional?

Answer: Technically, you wouldn't have to use subs or functions in a program, but I REALLY wouldn't want to try to maintain an application that didn't break down the code in some way or another. You use subs and functions to break your code into logical sections. This helps you easily find the code you need to look over/isolate bugs, etc. and also helps you re-use code for similar tasks (ie. sort routines, error handler routines, etc.) You use a sub when you need to perform a specific task and you use a function when you need to perform a specific task AND return an answer or value. Would I consider Subs/Functions optional? No. If you have an application that is actually going to do something, you pretty much will need to use subs or functions to get the job done in a way that is practical for real world use. I don't HAVE to use punctuation in any of my writing, but I do because it makes sense and is easier to interpret for everyone.

2. What is the concept behind using a module or not using one?

Answer: Again, this goes to organization/re-use of your code. If you have code that will be accessed by more than one form in your app, put it in a module to make it available to all the forms. That way you're not entering the same code more than once in your app. For example: I have a module called modReg that I use over and over. It contains subs and functions that I use strictly for reading/writing/accessing info in the registry. If I want to write a value to the registry, I know exactly where I have the code... in modReg. If I have a problem with code that is accessing the registry I know exactly where I need to look... in modReg. If I have another app that needs to access the registry... I just add modReg. Get the idea?

4. How about option explicit?
Answer: Option Explicit is a pretty good way to check yourself. It requires you to Explicitly define all of your variables. It can also help catch typos.

Example: If you didn't use option explicit...

Code:

---

strTemp = "Hello World"
Debug.Print strTepm

---

You wouldn't get an error in VB, you would just get an empty string printed out. Why? Because strTemp is mis-spelled in the debug.print. Option explicit will catch this and either have you declare both spellings or correct the one you mis-spelled.

Hope this helps.

Programming without subs, That's what my mum used to do before they invented keyboards and screens and you programmed with holes in a piece of card and couldn't leave your cave at night because a Dinosaur would eat you. with a subroutine you can write code once and use it again like the guys above say. If you're just starting VB learn about class modules too, it's the best time to learn them, they're the same principal but better, you'll think they're pointless at first but then you won't be able to live without them. For re usable code you should always put it in a class module rather than a standard module, that's why they don't let you make standard dlls in VB.(Trust me, they don't)

Public Vs Private

Private, unless you need to use the function outside the file you're working in, say you have a function Addem

Code:

---

Function Addem (Thing1 As Long, Thing2 As Long) As Long

    Addem = Thing1 + Thing2

End Function

---

this is a completley useless function BTW, it's just an example.

now imagine you have 2 forms

Say you only need to use this function in form1, put it in form1 and make it private, that way you can't get at it in form2, if you need it in form2 as well make it public and put it in a module.

always make subs and variables private if you can, it's good practice.

Well, once again, a wealth of information provided by the VB-Gurus. I sincerely appreciate the quick responses. Just increased my library by the tune of 3 books, all via Microsoft Press. They seem to be very thorough.

Just used a sub in my current project. It is working great.

Thanks again,
Sal

I'm really censorious about using subroutines and function, i'm a game developer and performance is the keyword for me, so while subroutine calls may only take from 1,2 to 4 µs, it's extreemly important not to overuse them where i have the codes like loops, classcalls and other frequent and timecritical code. I'm now working on performance test on a runtime script for a game and a shell replacement so even small things like select case have to be split up for best performance. Otherwise I use subs and functions very often to get my code as handy as possible. I had a thought about removing as much subs and functions as possible before the final compile so that it would only have events and methods with static vars, to gain highest possible performance but never tried. As a tip, u could use property get/let/set if u didnt already know.

Additinally to what was said about modules, they are absolutely needed if u work with the addresof operator, you have to put the procedure in a module. Modules can contain public enumerations, UDT's and declarations. They can be accessed without using Modulename.method or Modulename.variable (of course if you have many modules u will have easier to find them)

I never use Option explicit when i start with something new. When i have got into some hundred lines and make my first compilation, i will put option explicit and declare everything to check everything, Option explicit slows down programming, much like using prefixes to variables. That's later work for me.

Sam, i think Classmodules are more like UDT's with code rather than modules. Looking from this side it's much more interesting to introduce classmodules than to think they are modules in instances.

Private is good for hiding tons of things from the oo interface we work with, ie classmodules can pretty much loose its handyness if you have tons of public members that u never use from outside. Yeah, put them private as much as possible.