Why does SQL developer suggest a different format for a procedure that works?

This is my original procedure that works beautifully:

create or replace PROCEDURE EXTRACT_0_CPP AS
    CURSOR c_data IS
        SELECT cpp,
               rfu1,
               rfu2,
               mean_rfu,
               charge_ph7_4,
               hydropathy
        FROM   cpp
        ORDER BY LENGTH(cpp);
    F1 UTL_FILE.FILE_TYPE;

BEGIN 
    F1 := UTL_FILE.FOPEN( location => 'EXTRACT_DIR',
                          filename => '0_cpp.TXT',
                          open_mode => 'w',
                          max_linesize => 32767);
    FOR cur_rec IN c_data LOOP 
        UTL_FILE.PUT_LINE (F1, 
                            cur_rec.cpp || ':' ||
                            cur_rec.rfu1 || ':' ||
                            cur_rec.rfu2 || ':' ||
                            cur_rec.mean_rfu || ':' ||
                            cur_rec.charge_ph7_4 || ':' ||
                            cur_rec.hydropathy);                     
    END LOOP;
    UTL_FILE.FCLOSE(F1);
END;

But SQL Developer gives me a squiggly red line under SELECT and suggests I change it to this:

```
create or replace PROCEDURE EXTRACT_0_CPP AS
CURSOR c_data IS
SELECT
"A1"."CPP" "CPP",
"A1"."RFU1" "RFU1",
"A1"."RFU2" "RFU2",
"A1"."MEAN_RFU" "MEAN_RFU",
"A1"."CHARGE_PH7_4" "CHARGE_PH7_4",
"A1"."HYDROPATHY" "HYDROPATHY"
FROM
"C##ELLIE"."CPP" "A1"
ORDER BY
length("A1"."CPP");
F1 UTL_FILE.FILE_TYPE;

BEGIN
F1 := UTL_FILE.FOPEN( location => 'EXTRACT_DIR',
filename => '0_cpp.TXT',
open_mode => 'w',
max_linesize => 32767);
FOR cur_rec IN c_data LOOP
UTL_FILE.PUT_LINE (F1,
cur_rec.pk_cpp || ':' ||
cur_rec.rfu1 || ':' ||
cur_rec.rfu2 || ':' ||
cur_rec.mean_rfu || ':' ||
cur_

On the subject of why it would suggest a different format when the code already works, of course it's possible to have poorly formatted code that works, so in principle there is no reason why you shouldn't consider layout or refactoring improvements that might make the code more robust, efficient, or easier to maintain.

However, double-quoted names are poor practice because they hide naming errors and force you to specify upper/lowercase, and the result is less readable than the original. They are really a portability feature for use with third party applications that have weird table names. Code generators tend to slap double quotes around everything because it's easier to do that than to detect whether they are actually needed in each case. There is no way that

from "C##ELLIE"."CPP" "A1"

is any sort of improvement on

from cpp

except perhaps for the use of a table alias. It's a good idea to give the table an alias (without double-quotes!) and use it when referring to columns. But "A1" (or even a1) is the kind of table alias that only a computer would dream up. It would be far better to use an alias that is some kind of abbreviation of the table name, perhaps in this case c. Imagine if you were joining six tables - now which one is a3? Oh right, that's ORDER_DETAILS. (Though in this case the table name is so short that there is no point aliasing it.) So,

SELECT "A1"."CPP" "CPP"
FROM   "C##ELLIE"."CPP" "A1"

would be far better as just

SELECT c.cpp
FROM   cpp c

(I'd also lowercase it because this isn't 1974 and my editor highlights language keywords using colours and bold, but we'll let that go.)

Hardcoding schema names is poor practice because it's at best redundant (the object is in the schema you are already working in so it adds nothing except needless complication) or worse, it limits portability (if you ever rename the schema or move the code you'll have to go through it cleaning up the hardcoded references).

I'm sure this is a clever feature that means well, but in this instance it's not good advice.

StackExchange Database Administrators Q#274063, answer score: 5