Functions and procedures with a long parameter list are difficult to use, as maintainers must figure out the role of each parameter and keep track
of their position.
SET SERVEROUTPUT ON
CREATE PROCEDURE storeCube( -- Noncompliant, too many parameters
x1 PLS_INTEGER,
y1 PLS_INTEGER,
z1 PLS_INTEGER,
x2 PLS_INTEGER,
y2 PLS_INTEGER,
z2 PLS_INTEGER)
BEGIN
-- store the cube values
END;
/
BEGIN
storeCube(0, 0, 0, 1, 1, 1);
END;
/
DROP PROCEDURE storeCube;
The solution can be to:
- Split the function or the procedure into smaller ones
SET SERVEROUTPUT ON
CREATE PROCEDURE storeVector(
x PLS_INTEGER,
y PLS_INTEGER,
z PLS_INTEGER)
BEGIN
-- store the vectors values
END;
/
BEGIN
storeVector(0, 0, 0);
storeVector(1, 1, 1);
END;
/
DROP PROCEDURE storeVector;
- Find a better data structure for the parameters that group data in a way that makes sense for the specific application domain
SET SERVEROUTPUT ON
-- In geometry, Point is a logical structure to group data
CREATE TYPE point AS OBJECT(
x PLS_INTEGER,
y PLS_INTEGER,
z PLS_INTEGER);
CREATE PROCEDURE storeCube(
p1 point,
p2 point)
BEGIN
-- store the cube values
END;
/
BEGIN
storeCube(point(0, 0, 0), point(1, 1, 1))
END;
/
DROP PROCEDURE storeCube;
DROP TYPE point;
This rule raises an issue when a function or a procedure has more parameters than the provided threshold.
