[intro music]
Hi, I'm Steven Fuerstein.
And I write practically perfect PL/SQL
[music]
Hey there! I'm Steven Fuerstein.
I'm a PL/SQL developer just like you.
And what I want to talk about right now is what I
consider to be number one issue
and the number one best practice for writing really great code.
And its a really simple thing to say :
Never Repeat Anything!
If you can absorb that message
and figure out all the different ways it manifests in your code repetitions.
And the ways to get rid of repetitions, you will have amazingly clean code.
Code that is easy to read, Code that is easy to maintain.
Never repeat anything.
Now, the winning reputation
syncs up really closely with another concept in program in which people
are pretty often familiar with:
Hard-Coding.
And the corollary 'Never Repeat Anything'
is 'Never Hard-code Anything.'
So, what I would like to do
is talk about Hard-Coding.
Show you a piece of code
that is filled with Hard-Codings.
And hopefully, expand your mind, maybe blow your mind a little bit blow your mind a little bit
about what actually constitutes Hard-coding in a piece of Software.
[music]
So, let's take a look at this program, process_employee.
It consists of 33 lines of Code. It's very small.
And it is absolutely packed with Hard-Codings.
So, what I am going to do is, simply go line by line through this program.
And point out what I consider to be Hard-Codings.
And then, I'm gonna come back and dive into each one of those different kinds of Hard-Codings.
And talk about why they are so bad.
And how to get rid of them.
And some other measure in this year
hmm not as bad as others.
Line 1
Process Employee
So what I'm doing is passing this single parameter department_id NUMBER.
And the Hard-Coding in that line is the Hard-Coding of the data type.
I'm saying it is and will always be a Number.
Because of course the core concept of Hard-Coding
is that I have assumed that something's not going to change,
so I can expose its implementation.
I can say here's how it's defined, here's the underlying details in this thing.
And I can do it in more than one place.
Because it's never going to change.
So, the department_id hardcoded
as a date type of NUMBER.
Now, we will come back and talk about is that a big deal or not.
But that's Hard-Coding.
Same thing for Line 3, Line 4, Line 5.
These are all explicitly declared data types
using base data types like NUMBER and VARCHAR2.
And, most importantly, on Lines 4 and 5, Constrained declarations.
So, I'm saying last_name or the full name l_name can be at most a 100 characters long.
It's never gonna get to be bigger than that.
That's what the code actually says.
Its, it's never gonaa get bigger than 100 characters.
That's a pretty big assumption to me.
And that's when the other points of code related to Hard-Coding
and repeating things as we make assumptions.
But, focusing on Hard-Codings, let's keep going.
Line 7
A comment.
A comment.. Hard-Coding. Yes, that comment is a Hard-Coding.
Because it's hard coding the Rule. How do I construct the phone name of an employee.
Last comma first.
And look, there's a reference to the document, the Requirements Document.
I'm actually saying where this came from.
That's a pretty good idea but I'm repeating the rule:
What if the document changes and I have to go change this too?
So, that's a Hard-Coding.
Line 10, in which I'm selecting three different expressions -
the employee ID, the salary.
And then, I am constructing the full name.
I'm basically taking the.. rule that is defined in Line 7
back in Requirements Document,
And I'm expressing this code.
And I'm doing it that way because... it's so easy to do!
last comma first. What could be easier.
So, I will just do it there and there and there
and there and there!
All over the place.
[music]
So, moving along into the body of my program,
the executable section.
Line 17 contains a very interesting... sort of trivial Hard-Coding,
at least trivial in its resolution.
But potentially, problematic in terms of my code.
So, what could be Hard-Coded
about fetching a cursor the next row of my cursor, into 3 individual variables?
Well, the key word is 3.
What I've done is Hard-Code
into this fetch deamon, a dependency back on the SELECT statement.
What I'm saying in my code on line 17 is
this cursor will always return 3 different expressions.
And I'll drop them into these 3 different variables which I previously declared
using hard coded data types.
Its quite a little train of thought of code there.
So, the Hard-Coding is, what if the SELECT statement changes, what if I and another
comma or expression.
I'm gonna have to change the fetch deamon. So, there's a dependency
there's a Hard-Coding.
Lines 19 and Lines 24, well, those are probably the examples apart can make your eye
immediately went to when you saw this code because it stands out with a different color.
And it's also a literal value, and software programmers even the most
beginner among us knows that you're not supposed to Hard-Code literal values
because that's the sort of thing that can change all the time.
But we do it anyway.
We'll talk about how to get rid of it, it's actually the easiest form of Hard-Coding
to remove from your code.
Unfortunately, also the most common. But in this case there were actually two Hard-Codings
on Line 19. Two of them in one-line.
One of them is the number itself. The other is the expression
l_salary greater than 10 million though, it's not explicit in this piece of code
clearly.
There's an unarbitrary rule in my company that says, to be the CEO
you gotta make more than ten million dollars. That's the rule.
And if you make more than ten million dollars you must be the CEO.
So, the literal itself is Hard-Coded
and probably likely to change and not go down, go up.
But the other part of the Hard-Coding is the Expanded Formula.
As with Line 10, where I exposed the formula how you get the last name in the
full name of the employee
On Line 19, I'm explaining how do I figure out
if this person is the CEO. From exposing the implementation
Hard-Coding it. Moving on to Line 24, we have another example of the Hard-Coded literal.
repeating $10 million. I assume that the analyze competition procedure
has as its third argument - What is the
boundary, the floor that defines the CEO salary. Again, implicitly
there's a rule expressed. Moving on down to Line 28.
Commit. Yes, I do believe that Commit
is a form of Hard-Coding. It's a different kind of Hard-Coding
then say the Hard-Coding rule.
But, its performing a similar up role in my code.
If I Hard-Code rule, I'm exposing the implementation. When I Hard-Code COMMIT,
I'm Hard-Coding and exposing my Transaction boundaries. I'm thinking this point, I'm
gonna save my changes and there's no going back.
And, of course, you're saying to yourself, well, Steven, that's what Commit is supposed
to do. That's the whole point. I agree.
That's why I am saying, its a bit different from the others. The difference here,
is that I lose flexibility around testing. Particularly around testing
when I Hard-Code Commits. And we'll explore that in a bit more detail.
Moving down to the bottom Line 32, we've got several different Hard-Codings again.
Some of them will be obvious to you perhaps.
The fact that I'm Hard-Coding my Error message. I'm Hard-Coding my Error Number.
Those I think would stand out immediately. But one other point around
Hard-Coding here
is the raise_application_error invocation.
I'm Hard-Coding the mechanism I'm using to raise an error.
And again you might say, well, yeah but that's what I have to do, because I
need to raise this
application specific error. Maybe. But maybe, there's a better way to call
raise_application_error and
hide it from this layer of code.
[music]
So, 33 lines of code... I don't know,
10-12 different forms of Hard-Coding and there's a lot more that we
can really explore.
But that should give you a sense of a different way of looking at your code,
a different way of understanding
the kind of pitfalls that we can inadvertently enter into as we write our code.
And next, we'll explore the ways to resolve all these Hard-Codings.
[exit music]