Det jag träffade på igår är egentligen mer än en ren WTF. Om man programmerar så här, kan man lätt göra sig oumbärlig på en arbetsplats. Med fina ord kan vi kalla följande konstruktion Temporal coupling via global variables in persistent storage (för att göra en claim for fame). En annan rubrik skulle kunna vara “Work protection^2″ 
Tänk en PL/SQL-procedur på ca 500 rader som tar 5 in-parmetarar, anropar ytterligare några funktioner och procedurer, och vars egentliga flöde och happy path inte är helt självklara.
CREATE OR REPLACE PROCEDURE do_a_lot
(
L_A IN NUMBER,
L_B IN NUMBER,
L_C IN DATE,
L_D IN VARCHAR2,
L_E IN DATE
)
AS
-- Nåt tiotal lokala variabler
BEGIN
-- 50 Rader kod
SELECT INTO a_very_imporant_flag COUNT(*) FROM
(
-- Relativt enkel select på något 10-tal rader innehållande
WHERE table_a.attribute=table_x.attribute
AND table_a.anotherattribute=L_A
AND table_a.attribute=table_b.attribute
...
)
-- Sedan igen:
SELECT INTO a_very_imporant_flag COUNT(*) FROM
(
-- Relativt enkel select på något 10-tal rader innehållande
WHERE table_a.attribute=table_y.attribute
AND table_a.anotherattribute=L_A
AND table_a.attribute=table_b.attribute
...
)
-- 200 snarlika rader
-- 200 rader affärskritisk logik som beror på resultat från ovan
END;
Jag har strukit under två rader ovan. Dessa innehåller den dolda parametern! Det man nämligen måste veta för att ta rätt väg genom proceduren är table_b.attribute per default är NULL, vilket är helt fel. Istället ska man sätta det värdet innan man anropar proceduren, så att det förväntade resultatet uppnås.
Det här kanske blev lite rörigt förklarat, men sammanfattnigsvis:
Den temporala kopplingen ligger i att man måste anropa någonting som sätter table_b.attribute till icke-NULL, som också är den hemliga globala variabeln.
Sätter man detta i system är man behövd för alltid.