Late to this, but I use includes with code in two situations:
1. As standard library pieces managed through a pre-compiler, usually for
platform-dependent sections. For example, I have standard includes for
getting command line arguments, reading and writing from ini files and so
forth. The
I want to thank each contributor to this thread for the reasoned and
professional responses.
As always, very illuminating and instructive to be a part of this list.
Thank you each.
-Baker
This communication, its contents and any file attachments transmitted with it
are intended solely for
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
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
-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
'
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
Baker,
In production at my current site I have used Include only once, but for reasons
very different from what has already been discussed. I have a Shipment print
program customized into a true monster. It had not been rolled forward during
previous vendor (Dataflo) upgrades because of the
...@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
, Feb 8, 2012 6:21 am
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
it.
-Original Message-
From: David A. Green dgr...@dagconsulting.com
To: 'U2 Users List' u2-users@listserver.u2ug.org
Sent: Wed, Feb 8, 2012 6:21 am
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
, 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
Piping in with contrary notions all the way across the board! See my
remarks at --[SJ] in four places, if you like.
On 07/02/12 23:46, Kevin King wrote:
An include is fine for declarations, but not for executable code due to
the fact that individual lines in the include cannot be debugged (on
An include is fine for declarations, but not for executable code due to the
fact that individual lines in the include cannot be debugged (on Unidata).
Declarations like EQUates and common blocks are best uses for includes.
The need to break apart big routines due to some arbitrary limit (i.e.
On 07/02/12 23:46, Kevin King wrote:
An include is fine for declarations, but not for executable code due to the
fact that individual lines in the include cannot be debugged (on Unidata).
Declarations like EQUates and common blocks are best uses for includes.
The need to break apart big
I agree with Wols; a subroutine takes more memory and is slower to launch
but is so much easier to work with in any sized system. It's funny, our
subroutines are oddly similar to how Microsoft implemented DLL wrecknology
for Windows, but we've never had the kind of hell that Windows programmers
There are plenty of reasons to include code, and issues like variable
assignment should be able to be addressed with minimal care as to scope of the
variables -- if you use I in a for/next loop and include or execute some
code in the loop that also uses I, U will get what you deserve.
As per
From: Kevin King
It's funny, our subroutines are oddly similar to how
Microsoft implemented DLL wrecknology for Windows, but
we've never had the kind of hell that Windows
programmers experience. Funny how that works... :)
I completely disagree. Have you never been working on code in a
17 matches
Mail list logo
