Like with most things I'd say it depends.
I have worked with quite a few systems that use standard includes and
haven't noticed that those were harder to maintain than those that don't.
The reason being that those includes never get changed.
Usually these include equates (TRUE, FALSE, VM, AM etc.), commons,
opening standard system files (error messages, personal work files and
so on), housekeeping and/or wrapping up at the end of the program.
Debugging is also no problem since you have compile options that not
only generate a symbol table but also make the included code visible (in
UniData just use -Z2 -D).
If you use includes like that then at least 2 of your points become invalid.
That said, I don't understand what you mean with "installing updates
requires compiling the world".
If your software vendor uses includes you haven't got a choice and if
the software is developed in-house you define the standards.
And one of those standards should be, 'Don't change the standard includes!'.
So I can't see any disadvantage in using includes per se.
To the contrary.
You just copy the parts with the includes (in our case top and bottom)
of an existing program into an empty item (or create a template) and
start writing your code and you don't have to worry about your system
wide standard variables.
On 08/02/2012 15:35, Tom Whitmore wrote:
I would agree that code in includes provides a faster program than making an
external subroutine. I had performed tests when milliseconds counted, but now
systems are so fast the advantage is not noticeable.
Putting code in includes:
Makes debugging harder
Installing updates requires compiling the world to make sure you get
all the programs that use that include.
Maintenance costs are higher
> From my perspective, just say "NO" to code in includes. The cost is too high
with no real benefit.
Tom
RATEX Business Solutions
-----Original Message-----
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Baker Hughes
Sent: Wednesday, February 08, 2012 10:15 AM
To: 'dgr...@dagconsulting.com'; 'U2 Users List'
Subject: Re: [U2] Including Code - A Best Practice?
David,
Could you elaborate a little more on your two positive arguments? Thanks for
your insights, and all those shared from others so far.
Thank you.
-Baker
-----Original Message-----
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of David A. Green
Sent: Wednesday, February 08, 2012 8:21 AM
To: 'U2 Users List'
Subject: Re: [U2] Including Code - A Best Practice?
I don't think using an INCLUDE is bad, but it must be done in the right way.
Pros:
* It is the fastest way to use reusable code.
* It can be debugged just fine if you use the correct compile arguments.
Cons:
* You must, MUST, address the variable names. I always prefix mine with
CODE$NAME where CODE is the prefix I've chosen for my INCLUDE and should be
unique for your system.
* You must recompile all instances if you want the change to be updated
everywhere.
* More difficult to edit program logic, unless you have a nice editor that
brings in INCLUDES/INSERTS for you automatically.
David A. Green
(480) 813-1725
DAG Consulting
-----Original Message-----
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Baker Hughes
Sent: Tuesday, February 07, 2012 4:05 PM
To: U2 Users List (u2-users@listserver.u2ug.org)
Subject: [U2] Including Code - A Best Practice?
A friendly discussion arose recently among some U2/MV Developers about whether
to include code.
If any of you have opinions about the positive aspects or negative aspects of
this practice, please respond. Should it be adopted as a best practice, or
rejected as special situation use only?
Many shops probably include long sections of variable assignments, or perhaps
globally opened files. This is pretty much accepted everywhere as a good
practice.
In question here is the insertion of actual code - business logic or screen I/O
programs or code snippets.
Maybe you know of methods to overcome some of the obvious downsides:
unintended reassignment of local variables, difficulty in debugging, others.
What are the positive upsides? Performance gains?
What is the longest snippet you think should be included, if allowed?
What advantage has included code over a CALL or a Function? Reuse. What else?
Can the downsides be mitigated satisfactorily to justify the gains?
Thanks so much.
-Baker
This communication, its contents and any file attachments transmitted with it
are intended solely for the addressee(s) and may contain confidential
proprietary information.
Access by any other party without the express written permission of the sender
is STRICTLY PROHIBITED.
If you have received this communication in error you may not copy, distribute
or use the contents, attachments or information in any way. Please destroy it
and contact the sender.
_______________________________________________
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
_______________________________________________
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
_______________________________________________
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
