What is meant by Defensive Programming?
-
No matter how my team-members code, my code should work fine :confused:
-
No matter how my team-members code, my code should work fine :confused:
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.
-
No matter how my team-members code, my code should work fine :confused:
It works on my computer... ;P
-
No matter how my team-members code, my code should work fine :confused:
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
-
It works on my computer... ;P
-
No matter how my team-members code, my code should work fine :confused:
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!! >>
-
No matter how my team-members code, my code should work fine :confused:
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)
-
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...
All in one Menu-Ribbon Bar DirectX for WinRT/C# since 2013! Taking over the world since 1371!
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"
-
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
-
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.
-
Well you are right My example was poorly designed.
I'd rather be phishing!
-
No matter how my team-members code, my code should work fine :confused:
