|
Buck, Thanks for the post, I think you make a lot of good points and I think this does belong in RPG, I tried to think of where it might be reposted but I didn't come up with something. ----- Original Message ----- From: "Buck Calabro" <Buck.Calabro@commsoft.net> To: <RPG400-L@midrange.com> Sent: Tuesday, June 26, 2001 8:35 AM Subject: RE: Standards and Egos (was RE: ILE Propaganda) > >But what is a "trivial" standard? I think I saw > >mentioned in one post that which indicator > >to use for the help key was one. I don't think so. > > That was me. I meant exactly the opposite of what came across; sorry! When > I said trivial, I meant that it is one of those hundreds of decisions that > programmers make that don't have a sizeable impact on any one particular > program. Whether I use 90 or 99 doesn't really matter much in the larger > scheme of things - it's trivial. So, settle on an indicator and everybody > use that. That's one less decision I'll have to make when working on new > code. > > If there's a giant debate among the staff about the specific indicator, it's > a sign that either the staff are petty or that somebody hasn't explained the > fundamental concept that standard conventions free up time for programmers > to Think instead of do grunt work. I get what you mean now. You are exactly right. For years in the beginning of my career I used 80 as my "chain indicator." It was the dividing line between my work indicators and the CMDkey indicators. (as you can guess, I never used all the cmd keys! ;-) ) Changing that to use 9x for chain and miss and other temporary or work indicators was a trivial thing for me to do when I went to work for a company with that standard. In exchange for that trivial change, I had the freedom of knowing that I didn't have to scan every program before I wrote a few lines of code. I also knew whenever I saw certain indicators in the program what the programmer was up to. So, while this was a "trivial" standard to set, it sure paid back deep rewards in a code base of 10,000+ objects. > Like Peter C., my history is one of extremely mixed code environments. All > the way from one guy who avoided CHAIN because it is "too new and strange" > (he used Load, Sort, Print using MR) to one guy who used every new opcode > willy-nilly, leaving interesting things like 12 consecutive END statements. I must confess that I was that second guy at one time. I used to love to put every new thing in my code first chance I got. One thing it did teach me was to document the end statement of each loop. So I'd put a little note on the beginning statement and duplicate it in the comment section of the end statement. > My contribution to standards is to try to get the staff to agree to a few > easy to decide upon conventions like indicator usage (pick the current most > common), simple abbreviations (CUST# vs CUSTNO vs CUST vs CNUMB) and the > like. Once the staff are more comfortable with the simple ones, they may > actually ask for more! And that is exactly how standards get implemented. Over time. Very, very few companies have the luxory of starting a code base from scratch. Those guys can just make up standards and use them right away. The rest of us have the old "legacy code" problem. > Peter is right; it is not economically feasible to re-write the existing > code base to use the new standards. Whenever possible, slip the new > standards into the old code only when you're in there for something else. > That's not always possible, but if the programmers _think_ about doing that, > they're doing better than the random conventions being used now. > > If I'm in a fairly well written routine that's very old, I'll adhere to the > conventions in that code block because it retains the "feel" of the code. > If the code block is going to be re-written anyway, I use the new > conventions where they fit. Same thing for brand new routines. > > Conventions save our time for these sorts of decisions instead of > quarrelling over simple things. Exactly. Programmers should have bigger fish to fry! > Buck Chris Rehm javadisciple@earthlink.net If you believe that the best technology wins the marketplace, you haven't been paying attention. +--- | This is the RPG/400 Mailing List! | To submit a new message, send your mail to RPG400-L@midrange.com. | To subscribe to this list send email to RPG400-L-SUB@midrange.com. | To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.