Mar
1
Written by:
StevenFeuersteinTW
Monday, March 01, 2010 9:26 AM
We all know that hard-coding is a bad thing in software. But most developers think of hard-coding simply as typing a literal value into your program whenever you need it.
Example: the maximum value for a salary allowed in our company is $10,000,000. So I write code like:
IF l_employee.salary > 10000000 THEN
So what's wrong with doing this? Nothing - as long as the value is never going to change. But what's the chance of that happening? In fact, what's the chance of anything staying the same (never changing) in our application requirements and resulting code?
Almost nil.
So the best thing we can to improve the maintainability of our code is to internalize deeply the following:
-
Everything is going to change, so don't repeat anything.
-
Aim for a single point of definition (SPOD) for everything in your application.
-
Reference/invoke that SPOD whenever that "thing" is needed.
So instead of typing "10000000" when I needed to specify the "maximum value", I would do the following:
- Create a package to hold/hide the value (if an appropriate package does not already exist):
CREATE OR REPLACE PACKAGE app_config
IS
FUNCTION maximum_salary
RETURN NUMBER;
END app_config;
/
CREATE OR REPLACE PACKAGE BODY app_config
IS
FUNCTION maximum_salary
RETURN NUMBER
IS
BEGIN
RETURN 10000000;
END maximum_salary;
END app_config;
/
- Then I can go back to my code and change it to:
IF l_employee.salary > app_config.maximum_salary() THEN
No more hard-coding, and if the value ever needs to change, I only change it in the package body, so none of the programs that invoke the package will have to be recompiled.
Just about the biggest challenge when it comes to avoiding hard-coding in your application is to recognize when you are hard-coding. So here's a list of some of the scenarios which I believe represent a hard-coding:
|
Scenario
|
What to do about it
|
|
Any literal value
|
Hide the value behind a constant or a function. The function is a bit slower than referencing a constant but you can hide the value.
|
|
Constrained declarations like VARCHAR2(10)
|
Whenever you declare a variable with a limited size, you run the risk of raising a VALUE_ERROR exception. Better instead to define a subtype and hide the constraint behind the name of the subtype. Then when you declare your variable, use the subtype as the type.
|
|
Fetch into a list of variables
|
This is a hard-coding because if the number or type of expressions in the select list ever changes, you have to change the fetch statement as well. Better instead to fetch into a record based on the cursor with %ROWTYPE.
|
|
Business rules and formulas
|
Rules change all the time and usually get more complex, so you should always hide rules and formulas behind a function, and then just call the function.
|
|
SQL statements
|
This is not obvious to most developers, but every time you write an SQL statement you are taking a "snapshot" of a small slice of your business model - and that model is also always in the process of changing. So....hide all your SQL statements behind procedures (to change data in tables) and functions (to return data) - a table or transaction API. The Quest CodeGen Utility can help you do this.
|