|
>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. 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. 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! 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. Buck +--- | 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.