An example from the blog post above is varable l_required_info: this is declared in the main function can_show_information and then used within subprograms like player_can:
FUNCTION player_can (moment_in IN VARCHAR2)
RETURN BOOLEAN
IS
l_return BOOLEAN;
BEGIN
l_return :=
CASE moment_in
...
WHEN qdb_competition_mgr.c_resavail_closed
THEN
c_closed_or_ranked
OR ( info_type_in = c_see_correctness
AND l_required_info.players_accept_quizzes =
qdb_config.c_yes)
...
END;
RETURN l_return;
END;
(I removed some of the code to focus on the bit I'm interested in).
So this function player_can takes in one parameter moment_in and returns a value, but within it accesses variables from "outside" itself, e.g. l_required_info. I don't mind the constants like c_see_correctness, because constants are, well, constants. But the variables disturb me. Another procedure get_required_info changes the value of this variable, also without it being passed in as a parameter:
PROCEDURE get_required_info
IS
BEGIN
OPEN required_info_cur;
FETCH required_info_cur INTO l_required_info;
CLOSE required_info_cur;
My structured programming head makes me want to avoid this by passing all the values that each subroutine uses explicitly as parameters. But then it all becomes a lot more verbose of course. I have found myself writing code in the Feuerstein style, but then feeling edgy about having to defend it when others have to maintain it! (Most people are quite happy to write a single procedure hundreds or thousands of lines long of course!)
What do you think? Are my concerns legitimate or am I just behind the times with my "structured programming" tendency?