phsjhxx

5.2. Variables & Types
5.2.1 General
8. Try to use anchored declarations for variables, constants and types.
Reason Changing the size of the database column ename in the emp table from
VARCHAR2(10) to VARCHAR2(20) will result in an error within your code
whenever a value larger than 10 bytes is read. This can be avoided using
anchored declarations.
Example:
-- Bad
DECLARE
BEGIN
END;
l_ename VARCHAR2(10);
SELECT e.ename
INTO l_ename
FROM emp e
WHERE …
-- Good
DECLARE
l_ename emp.ename%TYPE;
BEGIN
SELECT e.ename
INTO l_ename
FROM emp e
WHERE …
END;
9. Try to have a single location to define your types. This single type could either be a type
specification package or the database (database defined types).
[CodeXpert 2812]
Reason: Single point of change when changing the data type.
No need to argue where to define types or where to look for existing
definitions.
10. Try to use subtypes for constructs used often in your application.
[CodeXpert 2812]
Reason: Single point of change when changing the data type.
Your code will be easier to read as the usage of a variable/constant may be
derived from its definition.
Example:
-- Bad
l_code_section VARCHAR2(30) := ‘TEST_PCK’;
-- Good
l_code_section types_pck.ora_name_type := ‘TEST_PCK’;
PL/SQL Coding Guidelines 19