Re: Would be really nice if...

"DA Morgan" <damorgan_at_x.washington.edu> wrote in message news:1109298868.45413_at_yasure...
> Ed Prochak wrote:
>
>> but when you present the reciept for 13 donuts and the boss only saw
>> 12, you'll be waiting a long time for that reimbursement check.
>>
>> Just admit it. select * is not safe.
>> Does no one practice defensive programming anymore?
>
> Not people who are totally devoid of formal training in the subject.
>
> SELECT * doesn't belong anywhere in real code. It only belongs in
> SQL*Plus.
>
> Were Haximus to write code such as SELECT * or SELECT * EXCEPT (if it
> were valid syntax) in any code I reviewed his qualifications for his
> job would be put into question immediately.

Well, I'd call you a bloody blowhard if you ever presumed to be in a position to review anything I produce. Since you are not and never will be in that position, you can stop blowing.

>> One guideline I've tried to follow in my development practice:
>> It's not how well it work when it works that's important,
>> but how well it works when it doesn't work that's important.
>
> It is similarly important to recognize that some code will not only work
> today but not tomorrow. Good coders write code that will survive in a
> dynamic environment.
>
> No doubt Haxi declares variables as:
>
> tabname VARCHAR2(30);
>
> rather than as:
>
> tabname all_tables.table_name%TYPE;
>
> and no doubt writes:
>
> INSERT INTO t VALUES (x,y,z);
>
> rather than
>
> INSERT INTO t (col1, col2, col3) VALUES (x,y,z);
>
> And I'll bet a Starbuck's latte' on it.
>
>> the "select * exclude" syntax doesn't buy you any protection over the
>> "select *" but an explicit list Always gets the data it expects.
>> Proponents of "select * exclude" are arguing for saving a little
>> programmer time now while leaving a big window for future errors.
>>
>> Ed
>
> Protection? It is just another lazy hack.

Morgan and Fitzy, both cozy occupants and lifetime members of "inside the box" thinking. Received on Thu Feb 24 2005 - 22:30:25 CST