So that you can easily find a particular procedure or set of procedures that access common data or provide a cohesive set of services, you can group procedures into modules with descriptive names. For example, if you've written a set of procedures that perform various accounting tasks, you could group them into a module and name the module "Accounting_Procedures." You would then know where to find any accounting procedure.
You can further group related modules into a single workbook. This makes it easier to turn the program into an add-in and distribute it. For more information about creating add-ins, see Chapter 12, "Creating Add-Ins."
Although you may want to store procedures in different modules or workbooks for organizational reasons, you may still want to be able to exchange information between them. To support data exchange across modules and workbooks, Visual Basic allows a procedure to access code and data stored in another module or workbook. For more information about accessing data in other modules or workbooks, see Chapter 2, "Variables, Constants, and Data Types." For more information about accessing code in other modules or workbooks, see "Calling Procedures in Other Modules" later in this chapter.
Simple applications can consist of just a single module; all of the code in the application resides in that module. As your applications get larger and more sophisticated, you add additional modules. Eventually you might find that there's common code you want to execute in several modules. You don't want to duplicate the code in both modules, so you create a separate module containing a procedure that implements the common code. Over time, you can build up a library of modules containing shared procedures, as described in the following section.