Abap allows you to modularize your coding in many ways. Making (parts of) your coding re-usable and chopping up your logic into eatable chunks is always a good idea.
SAP has provided many modularization methods which have been made available over time. When you are new to Abap, the possibilities can be overwhelming. Here's an overview:
FORM - ENDFORM, the Form routine
Form routines have been around from the very beginning of the Abap language. A form routine is part of a report, include or form pool, Forms can take parameters and from within a routine globally defined data can be accessed. Form routines from external programs can also be called, leading to a form of system-wide re-use. Note that access to global variables is not possible in external calls. If you want to find out whether your routine is called externally, the where-used list in the Abap editor will reveal external calls.
MODULE - ENDMODULE, the dynpro module
Modules sound like something modular, but it is not a way to organize coding. Modules are a necessity to control screens, there is a PROCESS BEFOURE OUTPUT event and a PROCESS AFTER INTPUT event which can each have (several) module calls. Modules do not have a parameter interface and data that is defined in a module may seem like a local definition, but these definitions are regarded global anyway. Good practice to call a form routine from your module.
FUNCTION - ENDFUNCTION, the function module
A function module (SE37) is effectively functionality that can be called from anywhere anytime, but it needs to be called from a report, module pool, other function module or external system to do something. There are over 250k function modules on the system (table TFDIR) and they are the pre-object oriented programming tool for modularization of larger programs. Function modules too have a parameter interface, they are part of a function group and the group can hold data that can be made available to other modules in the group or other calls to the same function module. Even though function modules live in a group, they have a unique name. Only a small part of the available function modules are ready to be re-used by us earth people. Many functions that should replace end-user screen-by-screen processing with an Abap alternative are available as Bapi (Business Application Programming Interface).
Function modules can also be called from remote systems, for which the function needs to be made RFC-enabled.
CLASS - ENDCLASS, the class definition
This is the driving force behind the Object Oriented paradigm. A class can be defined globally (SE24) and locally (in the Abap editor) and they play a big big role in modularization. Much much more on Object oriented programming elsewhere in this information pit.
METHOD - ENDMETHOD, methods
Methods are the routines for Object Oriented programming. They take parameters and they can even have a returning parameter as "method answer". Methods are always part of a class and for global classes a method can be called from anywhere. As part of the object oriented paradigm a method can be made private or protected, which means it is not always accessible from anywhere.
DEFINE - END-OF-DEFINITION, the Macro
Macro's are effectively also a modularization block, however one that should not be used for modularization purpose. If a certain sequence of Abap steps is repeated many times, the macro can make your coding shorter and more readible, but the same Macro can also make your coding very difficult to understand. Macro's take parameters as well, and they are effectively an editor shortcut: when the report is stored in executable manner, the Macro simple produces the full-blown coding, resulting in a report without any traces of the macro. Note that debugging in the coding of Macro's is not possible.