Type in the Data Type or You're Fired!

[Guest.Visitor]

Type in the Data Type or You're Fired!

** This thread discusses the article: Type in the Data Type or You're Fired! **
Ralph said: Speaking of ENDxx's, I was going to bounce over to a post about 7 levels of IF statements being readable in /free but in the spirit of laziness I'll just throw it in here. And I've rarely seen 7 levels of nested statements in /FREE. But, I have, quite often, see many more levels of this in older fixed format RPG, up to 30 before. Those are quite difficult to maintain. I'll take indented nested statements in /FREE over fixed format RPG anytime. Chris

[B.Bardini]

Type in the Data Type or You're Fired!

** This thread discusses the article: Type in the Data Type or You're Fired! **
In my experience, I cannot recall ever having any kind of problem because I or another programmer haven't put an 'S' or a 'P' in the type field of any kind of 'D' spec. In the examples in the article, both fields are 7.0, whether or not they were defined with an 'S' or 'P'. The 'I' spec is a different matter. A numeric field from 1 to 7 with 0 decimal positions is a 7.0 field if the type is 'S', but it is a 13.0 field if the type is 'P'. I have some sample code below, with the rpgle code and the field cross reference. Maybe I just haven't ever used a 'D' spec in a way that including the packed/signed type would matter. 'I' spec yes, I can't think of any reason to include the data type for a numeric field on a 'D' spec. Except, if I'm creating a data structure to define a chunk of data that includes packed/signed numeric fields. OK, maybe then. Feel free to educate me! Bruce

[gotto@islandpacific.com]

Type in the Data Type or You're Fired!

** This thread discusses the article: Type in the Data Type or You're Fired! **
Just a note related to data types and a strange implementation in the compiler. This is documented in the RPG manuals by the way. If you bring in fields via an external file description, fields defined as Signed in the file will actually be "brought into" your program as packed. While typically this does not cause a problem (the field is still numeric and can be used to interact with other numeric fields without issue), it becomes a problem when you use that field to interact with a procedure. If you define the procedure to "expect" a signed field as a pass-by-reference parameter, using this not-so-signed field on the call will fail because it is actually stored in a packed format. If you pass-by-value you won't have this problem. To solve this problem you have to have the file's fields defined in a data structure as well, as is done below. This preserves the "Signed" definition for the field. My guess as to IBM's reasoning for doing this is that fields brought in via the F-spec are defined as stand-alone fields to the program. So their stored size doesn't matter and I guess it is more efficient to use them in packed form. In a data structure, however, the phyiscal field length does matter because the data must take up certain bytes, therefore the actual type is preserved. This is a nasty little gotcha. Garrett

---

Code

[M.Savino]

Type in the Data Type or You're Fired!

** This thread discusses the article: Type in the Data Type or You're Fired! **
Chris, We don't use /FREE here so I can't speak to that. But having worked with many VB programs where we faithfully indented our code, IMO it's great when you can See the matching IF-ELSE-END on a single screen or page and when there are no more than 3 to 4 nested levels. And if that were the case, I wouldn't have much trouble following the code even if it weren't indented. But in my experience, even at 4 levels deep, there's a good chance that by the time the rest of the code has been added, you won't be able to see all the logic contained at the first level on a single screen. And once the IF-ELSE-END are no longer in sight of one another and anytime the code is deeply nested, there's no way that I can visually tell what level an isolated piece of code is at. So at that point, the indentation looks pretty but really isn't making the code much more readable. Which I think brings us back to Ralph's point. And one last thing for Ralph: On the Buffet table, should the luddites be placed before or after the crudites ?? ;-) Mike

[David Abramowitz]

Type in the Data Type or You're Fired!

** This thread discusses the article: Type in the Data Type or You're Fired! **
Ralph Daugherty observed: I rarely see generic END's Haven't been around much converted (or non-converted) S/36 code? Dave

[David Abramowitz]

Type in the Data Type or You're Fired!

** This thread discusses the article: Type in the Data Type or You're Fired! **
After a quarter century in this field I have recognized what I believe to be a universal truth. That each and every programmer thinks that their own stuff is golden, and everyone else's methodology is crap. And this is how something that should be a learning experience turns into an arguement. Dave

[Guest.Visitor]

Type in the Data Type or You're Fired!

** This thread discusses the article: Type in the Data Type or You're Fired! **
Hi Mike, You're preaching to the choir... I concur. Chris

[TCC]

Type in the Data Type or You're Fired!

** This thread discusses the article: Type in the Data Type or You're Fired! **
(1) An SEU option to flag the data type if left blank (Do you think anybody would turn it on?). (2) An optional compiler diagnostic/error message to flag data types left blank (Do you think anyone would enable that message?) (3) While you're on vacation dream up an Xtool that would read thru your source library and report the 'errors' and optionally interactively let you 'fix' the offending lines on the fly. (Do you think anybody would buy it?)