Type in the Data Type or You're Fired!

[pjmyers@ix.netcom.com]

Type in the Data Type or You're Fired!

** This thread discusses the article: Type in the Data Type or You're Fired! **
I laughed out loud when you said that if you already know this stuff it proves you're lazy. I knew all the stuff you wrote about, and I admit I'm a lazy coder in your sense. I'll try to remember to mind my P's and S's now, but I'm still too darn lazy to type an A. What on earth's your grouse about /FREE? The indentation of IF/DOW is all the justification anyone could ever need to dump fixed specs forever. You don't want to figure out how my numeric fields are defined, and I sure don't want to figure out your nested IF/ELSE's to the 7th level either! A lot of people won't use ELSEIF, which at least cuts down on the confusion.

[galliett]

Type in the Data Type or You're Fired!

** This thread discusses the article: Type in the Data Type or You're Fired! **
Let me say that you are perfectly RIGHT! In particular I am concerned with the data type subject. Your considerations are EXACTLY the reasons why i do appreciate a lot all those languages with strong constraints about data type specifications (i.e. java for example) and don't like very much VB and VBA "variant", or even the possibility itself for omitting the "option explicit" directive.

[Ray R]

Type in the Data Type or You're Fired!

** This thread discusses the article: Type in the Data Type or You're Fired! **
If your going to have long names, free-format, and logic controlled entirely from the calcuclation section, why not just write in COBOL? Of course you would have to do a program flow chart first but then anyone using free-form RPG and DOWHILE's and DOEND's and DODO's is already DOING that.

[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! **
Maybe that's the book you should be reading, Bob. People that disagree with your coding style are not necessarily lazy or bad programmers & I resent the implication. You make a good argument for entering the data types if someone is worried about an inexperienced coder that doesn't know the language reading one's code, but I for one do not intend to have some forgetful old guy touching my code. Besides, why in the heck are you coding fields in I specs anyway? A good coder would have re-created his files externally a long time ago. And why aren't you using the LIKE keyword in your D specs -- Don't you know anything? As a fellow consultant I can't imagine running around insulting potential clients like that. Your last two articles have been awfully bitter - perhaps you need a vacation.

[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! **
That question was answered 10 years ago when IBM stopped enhancing COBOL. While this was not always true, today, RPGLE is simply the more powerful lanuage of the two.

[R.Cozzi]

Type in the Data Type or You're Fired!

** This thread discusses the article: Type in the Data Type or You're Fired! **
Yes I always need a vacation. Input specs? Never use them--as usually the code is just examples of specific things/context. I had to be complete. "Forgetful old guy" and someone who doesn't know the language are two different things. Don't you want more people using RPG IV? Don't you want more people entering this marketspace? I'm more concerned about identifying the obscurities in RPG IV than whether someone wants to justify NOT using data-types. On the topic of ELSEIF... I do use them on a V5 machine when I get on one. Mine is still on V4R5 and my examples often reflect that (hence few QUALIFIED data structures). When the new box comes in, I'm sure I'll start uing V5R1 and V5R2 synax since the majority of machines are now on V5R2 and later. Field Referencing? I think a few RPGer's have gone too far with field referencing. It seems there are a number of people who don't see grey, they only see black and white. Hence, they _always_ use field referencing even when it cause obscurity. The irony here is that I find that those that go overboard on Field Referencing are often the same people who refuse to use /COPY because "they can't see the code in debug mode".

[R.Cozzi]

Type in the Data Type or You're Fired!

** This thread discusses the article: Type in the Data Type or You're Fired! **
The use of a computer programming language has nothing to do with which one is better. You can always make the langauge better, as has been done to RPG IV in the last decade. The reason we don't use COBOL is because we don't use COBOL. It is the same reason we don't have really cool packaged software on tihs box, the iSeries market doesn't buy many packages written in COBOL when compared with the sale of RPG packages. So why don't we use COBOL, because we use RPG IV.

[bharder@nlrha.ab.ca]

Type in the Data Type or You're Fired!

** This thread discusses the article: Type in the Data Type or You're Fired! **
Ummm, I've always viewed coding as a continuum. The more "good" techniques you use, the better your code is. I define "good" as being things which make your code more: 1). ledgible; 2). faster; 3). integrated; 4). portable; 6). modular; 7). and which enable you to write less of it. It's not always possible to choose techniques which do all of these things at the same time, so then you have to choose. In particular, goal 1 may conflict with the other goals. That's when you start using comments, to add the clarity back to your programs. Remember comments? They're good. Use more. Now, when it comes to field referencing, I can't agree that they add clarity in a tactical sense. The problem is simply the indirection they cause (you have to look somewhere else to find the field definition). The field size actually matters when it comes time to input or output the field on an actual physical device and/or form. Nevertheless, you use them, always Bob. Even when they cause obscurity. Why? Strategically, if you've constructed your system well with Field Reference Files, it makes sense. You have effectively implemented a master data dictionary. Now if you want to make that G/L number larger, make the change in the FRF and recompile your application system. You may have to adjust your input and output forms, but a basic implementation of your change will be there. That's because there is only 1 true definition of a G/L number, and every other instance of it refers back to the original definition. So your FRF isn't just a handy list of fields. It's THE master source for field definitions in your system.

[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! **
I'm always amazed that there are those in the industry that spend so much time on such trivial things! The task of all of my developers is to solve business problems, not worry about such things as packed vs. zoned documentation. I'll never look at a programmer during a performance review and reprimand them for not documenting their numeric type fields. It's just not important in the grand scheme of things. I'd much rather have them spend their extra time learning HTML or something NEW as it relates to business solutions. Whew! Must be a slow month for trade press writers. ;-) chuck Opinions expressed are not necessarily those of my employer.

[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! **
Chuck, I think it does matter. Like Bob says, it could cause you much more time finding a bug in a program. I have dealt with this very issue. And it is bad coding without it and creates some confusion in my mind as I'm reading the code. But this whole concept of a programmer performance review sounds great! I wish somewhere in my 20 year career someone would have sat me down and told me about my code. Never happened. In fact, there are a few former coworkers that could have used this too! ha ha. True, firing someone for this is silly. But 'At Will' employment will get you booted for something even more trivial. Bob gets some attention with this statement and makes a good point in the process. I agree with another guy above. He seems a little on edge lately. But I like it. Keep it up Bob! You can go on vacation, but you gotta promise to come back.

[BVining]

Type in the Data Type or You're Fired!

** This thread discusses the article: Type in the Data Type or You're Fired! **
Please review the V5R3 ILE COBOL Reference manual in the Information Center. It includes a section highlighting the changes made in various releases (V5R3, V5R2, V5R1, V4R4, V4R2, V3R7...). There have been significant enhancements made to COBOL on i5/OS so I don't quite understand the "IBM stopped enhancing COBOL" assertion. Bruce Vining

[R.Cozzi]

Type in the Data Type or You're Fired!

** This thread discusses the article: Type in the Data Type or You're Fired! **
I think the problem is not what I say, but perhaps how you react to what I say. If you're a bit thin-skinned, well I'm sorry to have offended you, but not for what I said. I mean, cowboy-up here will ya, we're talking about data types not killing puppies.

[R.Cozzi]

Type in the Data Type or You're Fired!

** This thread discusses the article: Type in the Data Type or You're Fired! **
Chuck, As programs on the iSeries get more and more sophisticated, subtle or trivial things are where the errors occur. You want your programmers to learn HTML? Good. Make sure they know the trivial thing that the CGI Header needs to be followed by two line feed characters, and not a "blank line" as some iSeries techies refer to it. That is two consecutive X'25' symbols with no embedded blanks or it will not be recognized. Also, make sure they know the trivial fact that HTML is generally case-insensitive, but that JavaScript is not. So while many people name input fields in an HTML form in mixed case, JavaScript requires that you refer to those field names in the same upper/lower case combination or it will not find them. What else? Oh, how about this… Server side includes are embedded in a comment in HTML. But there is a trivial thing to remember; there is no space permitted between the leading command symbols and the SSI statement, however there is at least one space required after the SSI statement and before the closing comment symbols. Slow news day? Yes, it always is, and yet look at the responses this trivial thing has prompted so far today. Must be a slow day in the industry too.

[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! **
pjmyers, Are you also too lazy to type the IF, DO, SL, FOR, MON on your ENDxxx's? Gosh I hope not! Not THAT'S grounds for dismissal. You're making your code difficult for the next programmer to read. Are you too lazy to put comments in your programs too? ... I agree with Bob, don't let the compiler or the next programmer infer the data type. Make it explicit. Just wondering... Chris

[R.Daugherty]

Type in the Data Type or You're Fired!

** This thread discusses the article: Type in the Data Type or You're Fired! **
I don't know about lazy, but I don't put an A on the character D specs. That's what our gurus have to bitch about? Holy cow. I rarely see generic END's. In the midst of this laziness talk, we need to remember that the person writing the code needs to understand it as well as those that follow. Whether unbridled energy or just the sheer need to be able to understand their own code, ENDxx go a long way in doing that so people use them. 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. What is really nuts is people using many levels if nesting as an argument for /free when in their very next exhale they would rightfully argue along with the rest of civilzed humanity that code shouldn't be nested very many levels to start with. So the code they argue that /free enables to be read wouldn't be written in /free anyway. Shouldn't be written in RPG fixed format either, but given how lazy we luddites are it's a wonder that billions of lines of code ever worked in fixed format. rd