That's what the compiler is for. After all, it has the final word on the sourse code and any 'pre-compilers'.
I'm having a similar dialog with someone on the D3 forum about their insistence upon 'changing' the syntax of data/basic statements as he feels that their syntax is not 'natural'. So he spends a lot of time developing his own pre-compiler that allows his new expressions to work for him yet get converted to the eventual data/basic compiler. I'm glad that you recognize that you're in a closed shop and don't have to worry about outside considerations. Given the vast amount of $OPTIONS that can be set in U2 systems, then you can customize your environment to exactly the one you like and go from there. Your two examples are just that, examples. I'm not going to stand on a soapbox and imply that you don't test. Not at all. But this kind of stuff comes up in the testing cycle of the project and if unexpected results occur, as in your 2 examples, then the testing has done its job in identifying a problem. Has EVERY instance of my typing VAL/100"R2#10" been perfect. Of course not, just as every example of your typing FMT(OCONV.... didn't work every time either. Whether yours gets caught in a pre-compiler, the regular compiler or the testing cycle, it will eventually get caught and repaired. Being in a closed shop is almost a luxury. You have a forced 'style' (the word 'standard' is too global) that allows your entire application to maintain a cohesive feel, look and, most importantly, programmability and maintainability. That's a luxury that I don't have at any of my clients. Zero. I am the current cook in the kitchen and based on the styles and date stamps of prior programmers, I can detect an average of 5-6 different thought processes in the code that all come together for each client's application. There's no reverse-implying a single standard (sorry, 'style'). Many on this forum have this luxury. And I'm sure many do not. Thanks Mark Johnson ----- Original Message ----- From: "Womack, Adrian" <[EMAIL PROTECTED]> To: <u2-users@listserver.u2ug.org> Sent: Thursday, November 22, 2007 1:56 AM Subject: RE: [U2] OCONV Extraction Question - Good Practice > Using FMT forces correct syntax use. Having the trailing formatting > characters, can cause all kinds of issues with small typos in the code > (especially when the compiler just takes it all in it's stride). > > Look at these two examples: > > * Accidentally inserting a space into a numeric constant > A = 123 4 > CRT A > * displays 123.0000 > > * missing out a colon or a comma > CRT "XYZ" "ABC" > * Displays ABC > > We use a syntax checking program which throws both of these out as bad > syntax, so the code never gets anywhere near production. IMO the > compiler shouldn't accept this type of formatting (or perhaps there > should be a compiler $option). Although, we are a closed shop and work > exclusively in PI/Open flavour, so portability isn't an issue for us. > > AdrianW > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of MAJ Programming > Sent: Thursday, 22 November 2007 2:54 PM > To: u2-users@listserver.u2ug.org > Subject: Re: [U2] OCONV Extraction Question - Good Practice > > I gotta ask. How is it a disaster waiting to happen. > > This 'best practices' exercise may die an early death with such > unauthorized conclusions. How are you judging the CRT example as > 'disasterous'. > > Mark Johnson > > BTW, the FMT expression may not play well with other MV flavours. Thus, > I tend to program continouosly to cover all of my client's needs. > > > DISCLAIMER: > Disclaimer. This e-mail is private and confidential. If you are not the intended recipient, please advise us by return e-mail immediately, and delete the e-mail and any attachments without using or disclosing the contents in any way. The views expressed in this e-mail are those of the author, and do not represent those of this company unless this is clearly indicated. You should scan this e-mail and any attachments for viruses. This company accepts no liability for any direct or indirect damage or loss resulting from the use of any attachments to this e-mail. > ------- > u2-users mailing list > u2-users@listserver.u2ug.org > To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
