X = 5; y = x; x = y; ??

cell18189

I've been tasked to refactor some SQL code, and while doing this, I found this oddity:


    IF LENGTH( v_valid_to) > 0 THEN
        v_regfac_tmp_row.end_date := TO_DATE( v_valid_to, 'YYYYMMDD');
        v_begin_date := v_regfac_tmp_row.end_date;
        v_regfac_tmp_row.valid_to := TO_DATE( v_valid_to, 'YYYYMMDD');
        v_regfac_tmp_row.end_date := v_begin_date;
    ELSE
        v_regfac_tmp_row.end_date := NULL;
        v_begin_date := h_eprs_job_status_pkg.C_END_DATE;
        v_regfac_tmp_row.end_date := v_begin_date;
    END IF;

Where v_* is a variable, v_begin_date is not used before or after this snippet, these are not references, AND All of this code was written by a single developer in a single check-in. There are also no related triggers.

Translated to simplified Pseudocode:

    IF LENGTH( p_valid_to) > 0 THEN
        x = p_valid_to;
        y := x;
        table.valid_to := p_valid_to;
        x := y;
    ELSE
        x := NULL;
        y := END_OF_TIME;
        x := y;
    END IF;

(Where  y is not used before or after this)

dhromed

Late.

No coffee.

Lackluster.

Imminent illness.

Playing Stupid's Advocate here.

cell18189

Yeah, maybe I should ask him. He's just around the corner.

pbean

It's for future optimizations.

Kiss_me_I_m_Polish

The common practice is to initialize a variable at least twice. Sometimes the compiler optimizes too fast and you should make sure it doesn't forget about your initial values.

Also, some variables should be unused, to miminize buffer overrun damage (there is no problem if an unused variable is overrun).The critical variables should be insulated in memory by a buffer of unused variables sitting to the left and right of them.

The "x=y; y=x;" pattern is a test. Some volatile values might obviously change between these. Also, buffer overrun.

Mason_Wheeler

What language is this, BTW? It looks a lot like Pascal, but Pascal doesn't use END IF (that's from VB) and it uses nil, not NULL. (That's from C.) So I can't help but wonder what this project is coded in...

toth

@Mason Wheeler said:

What language is this, BTW? It looks a lot like Pascal, but Pascal doesn't use END IF (that's from VB) and it uses nil, not NULL. (That's from C.) So I can't help but wonder what this project is coded in...

I would guess some dialect of SQL, given the OP:

@the op said:

I've been tasked to refactor some SQL code, and while doing this, I found this oddity:

cell18189

It's written in PL/SQL in an Oracle stored procedure.

Mason_Wheeler

Oh, PL/SQL. OK. I'd seen some flavors of imperative SQL before, but not Oracle's version. So I guess that makes sense.

blakeyrat

@Mason Wheeler said:

Oh, PL/SQL. OK. I'd seen some flavors of imperative SQL before, but not Oracle's version. So I guess that makes sense.

Other than the lack of BEGIN, I'm 99.44% sure that could be T-SQL as well. And even BEGIN I'm not sure about... is it required? Or do I just type it out of habit?

toth

@blakeyrat said:

@Mason Wheeler said:
Oh, PL/SQL. OK. I'd seen some flavors of imperative SQL before, but not Oracle's version. So I guess that makes sense.

Other than the lack of BEGIN, I'm 99.44% sure that could be T-SQL as well. And even BEGIN I'm not sure about... is it required? Or do I just type it out of habit?

BEGIN...END (not END IF) is required if the block is more than one line (and recommended even if it's one line), and the assignment operators are not as above (in T-SQL, they're just plain "=")

blakeyrat

Ah, good catch. I've read too much PASCAL in my life.