|
No matter how my team-members code, my code should work fine 
|
|
|
|
|
Getting the client to pay first. 
veni bibi saltavi
|
|
|
|
|
Make no assumptions (about system state or inputs)
|
|
|
|
|
I always assume the system is going to give me the wrong data at some point. Whether it's a garbage value to a null one, always assume it's going to be wrong at some point.
|
|
|
|
|
"Defensive programming is a form of defensive design intended to ensure the continuing function of a piece of software under unforeseen circumstances. The idea can be viewed as reducing or eliminating the prospect of Finagle's law having effect" [^]
IMO, this goes with design by contract[^] programming. (pre and post conditions)
In short, you make your own code fool proof according to the design and architecture (and contract) of the existing code.
BAD EXAMPLE BELOW ... DO NOT USED... I keep it there just because I suck this morning.
As a (very simplified example) (in c-ish language)
If the design (contract) say that p can be invalid, then you need to handle that case.
void f ( SomeClass* p )
{
p->doSomething();
}
will crash is p is invalid.
defensive programming will have something like:
void f ( SomeClass* p )
{
if (p)
p->doSomething();
}
or
void f ( SomeClass* p )
{
if ( invalid(p))
{
assert_and_log_message("invalid p in function f");
return;
}
p->doSomething();
}
In both case, your own code will not crash.
I'd rather be phishing!
modified 3-Nov-15 8:48am.
|
|
|
|
|
Looks like a great way to introduce bugs. Now the caller has absolutely no idea that the argument was invalid, and that the method didn't actually do what they were expecting it to do, and will continue to execute despite the system being in an invalid state.
Throwing an exception when given invalid input would be the ideal, but even crashing would be better than just doing nothing! 
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Well you are right
My example was poorly designed.
I'd rather be phishing!
|
|
|
|
|
Hey, props to you for just striking out your code instead of deleting it. I think it is fantastic when people are humble (and self-confident) enough to let others learn from their mistakes. (Especially because I'm sure I might have made the same one!)
|
|
|
|
|
I think it's probably very simple which probably already do...
it's when you write some public method you don't just assume that the parameter will be kind of alright, but you cater for inappropriate input, such as null, large integer (causing overflow) etc, etc...
|
|
|
|
|
Always validate your parameters and assume your user is an absolute moron. Then set up logging and early reporting messages back to you so that when they call you up all frantic you already have the problem solved. 
It's how Scotty does it... "Aye Cap'n"
|
|
|
|
|
Fundamentally the wrong way around, but with most languages you don't have much choice.
Really it should be guaranteed that all callers pass valid input, if they don't then it's the caller that's wrong, not the callee. But with defensive programming you'll get the assert in the callee, only at runtime, only if you're lucky, and it's up to you to figure out how it ever happened.
It's not like there's much of an alternative yet, but really calls that violate a callee's contract should be compile time errors, because if it's even possible to call something wrong, the caller is statically wrong.
|
|
|
|
|
A more generic answer:
Presume the user's brain is elephanted, or their out to get you. Really.
They do the most absurd things that no rational sentient being would ever consider - and if you ask them why, they often have no reason - but they'll find a way to break your code.
Or rather, assume the preceding paragraph is gospel - the user is the enemy - so defend yourself against an imminent attack.
Much of this, despite the rigorous coding practices suggested by others, comes from hard-won experience and much shaking of the head (and foul oaths).
Another important thing to remember is that you really can't test/debug your own code. You make it as perfect as you can, but someone who doesn't know what's under the hood should push the buttons.
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "As far as we know, our computer has never had an undetected error." - Weisert | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
It's like defensive driving. Run all red lights, stop signs, never yield, in other words, put everyone on the defensive.
Marc
|
|
|
|
|
Fitting the computer with Armer Response and hooking it up to the default "bleep" in your application.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
Passing the blame in meetings.
|
|
|
|
|
Here[^]
Starting to think people post kid pics in their profiles because that was the last time they were cute - Jeremy.
|
|
|
|
|
It means get dirt on program manager, or boss of program manager, so you will not be fired because they are afraid of you.
«I want to stay as close to the edge as I can without going over. Out on the edge you see all kinds of things you can't see from the center» Kurt Vonnegut.
|
|
|
|
|
It works on my computer... 
|
|
|
|
|
"I tested the code on my computer and everything worked smooth, I have no idea why it crashes so brutally on a different machine... perhaps that computer is the problem..." - me, while fixing a stupid typo.
|
|
|
|
|
First you need to remember your user are absolute bloody idiots who have no regard for logic and no common sense, now you need to deal with it, validate and check everything.
A REALLY defensive program does not need any internal error trapping. Better still just disconnect the keyboard and mouse, then they can't screw your app.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Assume you will have a software tester that will try to break the function you wrote (that is their job) in anyway they can think of without editing the actual function (thus by only modifying the inputs (input arguments/global variables)), and try to prevent them from doing so.
"Program testing can be used to show the presence of bugs, but never to show their absence."
<< please vote!! >></div>
|
|
|
|
|
I always thought about programming differently after I accidentally coded a few infinite loops that crashed because of lack of stack space, or what not...
Later, it was described as defensive programming.
My favorite example, is one I blew up. Given a string, pad it to the left until it is 32 characters in length.
A$ = " " + A$ until len(A$) = 32
Which, of course, if you are given a string that is already too long, this will crash.
So, quickly I learned
While len(A$) < 32 do A$ = " " + A$
Always look for the comparison that avoids doing work under the most conditions. Here, there are a LOT of times you know to stop. The = was limited to exactly one condition.
That one lesson, I have used over the years, and I refactor code that is logically correct when changed to be like this. The reduction of errors/issues is amazing. (truth is, I hate debugging, and prefer to desk check my code. I grew up with OVERNIGHT compilers, so syntax errors cost you a day. In fact, all errors cost you a day)
|
|
|
|
|
Kirk 10389821 wrote: While len(A$) < 32 do A$ = " " + A$
Why use a loop when you can do something like
A$ = Right(put 32 spaces in quotes here + A$, 32)
Curious - if I actually put 32 spaces in quotes, it gets trimmed. hmmm.
There are strangers on the Plain, Croaker
|
|
|
|
|
Oh, I have done it that way in a hurry!
But what happens when len(A$) is NEAR the limit of a string length (ie has less than 32 characters left). You could actually lose the right side of the string!!!
Also, the 32 was chosen for simplicity, as was the space. I believe the actual code had a variable for the length, and another for the padding character.
But the nuances is what makes defensive programming powerful. Most people don't think in terms of limits. They EXPECT a "small" string to be passed in when they are WRITING the code, and it NEVER dawns on them how the code could be called in the future.
I know from first (and second) hand experience that defensive style programming reduces errors and the debugging efforts required. I would rather fail with ASSERT() failures than to let code execute with bad parameters and pray for good luck.
|
|
|
|
|
I knew a VBA programmer who used "On Error Resume Next"  as the first line of every Procedure/Function/Method.
System never crashed. Half the code never ran but it never crashed.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
