I believe he means, as can often happen, that your file structure changes. You start with an invoice file of say 30 fields, and write 80 programs to reference that include. But down the road someone says oh hey we need to handle cases where we need to add a "extension with no penalty" date, or a "multiple methods of payment" or a "APS rejected date" or whatever to that structure.
Now you edit your include and add one or three more fields at the bottom say, but no program yet knows you've done that, until you recompile that program. You could select all the programs that include that equate table and recompile them all. You don't have to of course, but you could, most people would probably strengthen that and say you SHOULD. -----Original Message----- From: Mecki Foerthmann <[email protected]> To: u2-users <[email protected]> Sent: Wed, Feb 8, 2012 10:36 am Subject: Re: [U2] Including Code - A Best Practice? Like with most things I'd say it depends. have worked with quite a few systems that use standard includes and aven't noticed that those were harder to maintain than those that don't. he reason being that those includes never get changed. sually these include equates (TRUE, FALSE, VM, AM etc.), commons, pening standard system files (error messages, personal work files and o on), housekeeping and/or wrapping up at the end of the program. ebugging is also no problem since you have compile options that not nly generate a symbol table but also make the included code visible (in niData just use -Z2 -D). f you use includes like that then at least 2 of your points become invalid. hat said, I don't understand what you mean with "installing updates equires compiling the world". f your software vendor uses includes you haven't got a choice and if he software is developed in-house you define the standards. nd one of those standards should be, 'Don't change the standard includes!'. o I can't see any disadvantage in using includes per se. o the contrary. ou just copy the parts with the includes (in our case top and bottom) f an existing program into an empty item (or create a template) and tart writing your code and you don't have to worry about your system ide standard variables. n 08/02/2012 15:35, Tom Whitmore wrote: I would agree that code in includes provides a faster program than making an xternal subroutine. I had performed tests when milliseconds counted, but now ystems 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 rograms that use that include. Maintenance costs are higher > From my perspective, just say "NO" to code in includes. The cost is too igh with no real benefit. Tom RATEX Business Solutions -----Original Message----- From: [email protected] [mailto:[email protected]] n Behalf Of Baker Hughes Sent: Wednesday, February 08, 2012 10:15 AM To: '[email protected]'; '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 our insights, and all those shared from others so far. Thank you. -Baker -----Original Message----- From: [email protected] [mailto:[email protected]] n 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 ODE$NAME where CODE is the prefix I've chosen for my INCLUDE and should be nique for your system. * You must recompile all instances if you want the change to be updated verywhere. * More difficult to edit program logic, unless you have a nice editor that rings in INCLUDES/INSERTS for you automatically. David A. Green (480) 813-1725 DAG Consulting -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Baker Hughes Sent: Tuesday, February 07, 2012 4:05 PM To: U2 Users List ([email protected]) Subject: [U2] Including Code - A Best Practice? A friendly discussion arose recently among some U2/MV Developers about whether o include code. If any of you have opinions about the positive aspects or negative aspects of his practice, please respond. Should it be adopted as a best practice, or ejected as special situation use only? Many shops probably include long sections of variable assignments, or perhaps lobally opened files. This is pretty much accepted everywhere as a good ractice. In question here is the insertion of actual code - business logic or screen /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 lse? 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 re intended solely for the addressee(s) and may contain confidential roprietary information. Access by any other party without the express written permission of the sender s STRICTLY PROHIBITED. If you have received this communication in error you may not copy, distribute r use the contents, attachments or information in any way. Please destroy it nd contact the sender. _______________________________________________ U2-Users mailing list [email protected] http://listserver.u2ug.org/mailman/listinfo/u2-users _______________________________________________ U2-Users mailing list [email protected] http://listserver.u2ug.org/mailman/listinfo/u2-users ______________________________________________ 2-Users mailing list [email protected] ttp://listserver.u2ug.org/mailman/listinfo/u2-users _______________________________________________ U2-Users mailing list [email protected] http://listserver.u2ug.org/mailman/listinfo/u2-users
