== Why is this an issue?

Global variables can seem like a handy way to pass state information around in a program, but the use of global variables only works well in very small programs. As the code base grows, you'll need to understand every subprocedure's impact on the global state in order to understand how the program works. This is a task that quickly becomes impossible.


To control the situation, only the main procedure should be allowed access to global variables; it can then pass that state information to subprocedures as parameters. 


=== Noncompliant code example

[source,rpg]
----
     D FirstName       S             20A     
     D LastName        S             20A   

      /free
       FirstName = 'John';
       LastName = 'Smith';
       DSPLY FullName();
      /end-free

     P FullName        B
     D FullName        PI            41A
      /free
       return FirstName + ' ' + LastName;
      /end-Free
     P                 E
----


=== Compliant solution

[source,rpg]
----
      /free
       DSPLY FullName('John':'Smith');
      /end-free

     P FullName        B
     D FullName        PI            41A
     D  FirstName                    20A   Const
     D  LastName                     20A   Const
      /free
       return FirstName + ' ' + LastName;
      /end-Free
     P                 E
----


ifdef::env-github,rspecator-view[]

'''
== Implementation Specification
(visible only on this page)

=== Message

Pass "XXX" to this subprocedure as a parameter.


'''
== Comments And Links
(visible only on this page)

=== relates to: S2536

=== on 12 Sep 2014, 14:48:35 Ann Campbell wrote:
\[~pierre-yves.nicolas] do you find this rule interesting enough to provide code samples for me? The initial requester lost interest before doing so.

endif::env-github,rspecator-view[]