Procedures and functions can both use parameters to pass information back and forth between the module and the calling PL/SQL block.
The parameters of a module, part of its header or signature, are at least as important as the code that implements the module (the module’s body). In fact, the header of the program is sometimes described as a “contract”—between the author of the program and its users. Sure, you have to make certain that your module fulfills its promise. But the whole point of creating a module is that it can be called, ideally by more than one other module. If the parameter list is confusing or badly designed, it will be very difficult for other programmers to use the module, and the result is that few will bother. And it doesn’t matter how well you implemented a program if no one uses it.
Many developers do not give enough attention to a module’s set of parameters. Considerations regarding parameters include:
Too few parameters can limit the reusability of your program; with too many parameters, no one will want to reuse your program. Certainly, the number of parameters is largely determined by program requirements, but there are different ways to define parameters (such as bundling multiple parameters in a single record).
Should you use read-only, write-only, or read-write parameters?
How should you name your parameters so that their purpose in the module is properly and easily understood?