Comet SightingsMonday, June 30, 2008READ and her friendsThe recent  conversation on the Signature web site about the usefulness of the READ statement started me thinking. There is no question that READ is a weak sister. Her newer siblings EXTRACT and INQUIRE are much better. Not only do they do more, they tell much more about the intentions of the coder. When you see an INQUIRE in a program you know you are dealing with a file that is not going to be changed; an EXTRACT alerts you that this is a file that will be changed.The suggestion made on the web site in June 2008 was to change the  Comet run-time so that READ would act like INQUIRE. After all, if all the coder wants to do is get a record, and did not use an EXTRACT, then why not let the system treat the READ just as it does an INQUIRE. The suggestion was roundly denounced. The consensus was to leave old code alone; "If it aint broke, don't fix it." I could not agree more.Not the run time, the compilerMy suggestion is less dangerous. Rather than fool with the run time, make the compiler a little friendlier, a little smarter. The compiler should warn the coder that the READ statement is bad news and that INQUIRE or EXTRACT are the preferred statements. This kind of change would affect only new programs and programs that are being updated. And, if all you got was a warning message then you could elect to leave well enough alone when making a minor change to an old working program.Warning messagesAnd while we're taling about changing the compiler's warning messages maybe we can eliminate the useless warning about duplicate definitions. No, not the error message that says the same variable is defined with different characteristics. That's a real error. I'm talking about the warning that tells you that CNBR$ is defined three times in the source. When I see that warning message filling up the compile screen I want to yell, "I know, I know, I know it's defined three times in three USEFILES and I don't dare to change them."Warning you about non-errors that you can't change is not all that helpful. Now what I would like is a list of unreferenced statement labels and unreferenced variables. I like removing unreferenced statement labels so I can better see how the program logic works. And I like removing unreferenced variables for the same reason, BUT please don't tell me about unreferenced variables and statements in USEFILES. Please tell me about unreferenced statements and variables defined in the source program. Now that would be a useful warning message.How about WRITE?WRITE suffers from the same limitations as READ. It has been supplanted by it's big  brothers INSERT and REWRITE just as READ has been passed by EXTRACT and INQUIRE. Why not smarten up the compiler to gently warn the developer that maybe WRITE is not the best choice.I'm really hard pressed to find a good case for using a READ in new code but I can see at least one situation where I would use WRITE. I have designed some update progra