Why is this an issue?
Having functions and procedures which take too many parameters decreases the code’s readability and usability. It is likely that such a
function/procedure is not modular enough, and should be split into several smaller ones.
Noncompliant code example
With the default threshold of 10:
SET SERVEROUTPUT ON
CREATE FUNCTION sumWithTooManyParameters( -- Noncompliant, too many parameters
a1 PLS_INTEGER,
a2 PLS_INTEGER,
a3 PLS_INTEGER,
a4 PLS_INTEGER,
a5 PLS_INTEGER,
a6 PLS_INTEGER,
a7 PLS_INTEGER,
a8 PLS_INTEGER,
a9 PLS_INTEGER,
a10 PLS_INTEGER,
a11 PLS_INTEGER
)
RETURN PLS_INTEGER AS
BEGIN
RETURN a1 + a2 + a3 + a4 + a5 + a6 + a7 + a8 + a9 + a10 + a11;
END;
/
BEGIN
DBMS_OUTPUT.PUT_LINE('Sum is ' || sumWithTooManyParameters(1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11));
END;
/
DROP FUNCTION sumWithTooManyParameters;
Compliant solution
SET SERVEROUTPUT ON
CREATE FUNCTION sumCorrected(n PLS_INTEGER) RETURN PLS_INTEGER AS -- Compliant
BEGIN
RETURN (1 + n)*(n / 2);
END;
/
BEGIN
DBMS_OUTPUT.PUT_LINE('Sum is ' || sumCorrected(11));
END;
/
DROP FUNCTION sumCorrected;
