On 7/8/2014 9:48 AM, Henrik Rützou wrote:
Buck
this is very easy - take middleware service programs as CGIDEV2, HTTPAPI or
powerEXT. They all have a lot of subprocedures that shares global variables
within
the service program and general storage allocations otherwise they could
not run.
Looking at CGIDEV2, there is a global DS for IFS stat() called
StatusBuffer. That DS is used in 6 places. I am mentally stuck on
'could not run'. Is it not possible to refactor all the uses of stat()
into a wrapper that has the DS defined once? And along with that, a few
getters to retrieve the few variables the code base actually uses? This
seems to me that it was a choice rather than 'forced to do it this way
or it could not run'.
I have a similar feeling for XXXCGIPARS and bufDS. This would be harder
but still, it is possible to refactor out the CGI API calls into
separate subprocedures which do error checking, etc. and then write
appropriate getters to extract out the variables that the DS describes.
20 years ago I would not have been thinking this way, but after many
years of having to maintain code with a very low level of abstraction,
more and more I have the feeling that higher levels of abstraction are
easier to maintain. Global variables are one of those 'red flags' which
indicates (ha ha!) to me that my level of abstraction is too low.
An example which might have actually struck CGIDEV2 is changing the code
to accept variable CCSID input. Adding optional parameters to the
global DS means that one must hunt down all the references to that DS
and every one of the subfields in order to be sure that there is no
subtle failure introduced. A very typical example of this would be
allocating the wrong amount of memory and then reading 'too far' into
uninitialised memory space. If I'd have wrapped that DS with
appropriate setters and getters, I could still have the benefit of
global data (not put the DS into 6 parameter lists) but also have access
which obeys some rules (bounds checking, error checking, etc). If every
access in the module is done inline, and I forget to do bounds checking
in one of those 6 places, that is a bug waiting to happen.
I hope I was able to explain why I am confused about good design and
global variables. I know there are no absolute rules - all programming
is a compromise. The place I tend to use globals the most is for
something like DEBUG_FLAG which is read-only almost everywhere. It is
pervasive throughout the module, read in every subprocedure, and if
toggled on, does a log(thisVar, "Some message"). It does have one
setter which reads a table or data structure and sets DEBUG_FLAG on or
off. In this way I can turn debugging traces on for server processes
which have no UI. So I am not totally opposed to the idea, but I do
feel like I am cheating when I use a global variable.
--buck
On Tue, Jul 8, 2014 at 3:22 PM, Buck Calabro <kc2hiz@xxxxxxxxx> wrote:
On 7/8/2014 4:46 AM, D*B wrote:
Additinal note:
global data and coupling procedures by global data is not bad design!
Bad design is to define data global, which is needed only local!!!
Hi Dieter,
This surprises me, which means I probably do not understand what you
mean. Could you please give an example of good design that couples
subprocedures with global variables?
--buck
midrange.com
