|
Thank goodness for that, it's what keeps us in work.
~~~~~~~ <;,>< ~~~~~~~~~~~
|
|
|
|
|
Which is rare.
I always try to work out everything the user could possibly do wrong, and code to catch it.
If a user can do something to kill your software than at some point they will.
Defensive programming saves you time later, but requires more time up front cos you need to think about things fully.
Every man can tell how many goats or sheep he possesses, but not how many friends.
|
|
|
|
|
Well said, Chris.
I could not have said it better.
The theory is there, but full application of said theory is impossible, IMHO.
"the meat from that butcher is just the dogs danglies, absolutely amazing cuts of beef." - DaveAuld (2011)
"No, that is just the earthly manifestation of the Great God Retardon." - Nagy Vilmos (2011)
"It is the celestial scrotum of good luck!" - Nagy Vilmos (2011)
"But you probably have the smoothest scrotum of any grown man" - Pete O'Hanlon (2012)
|
|
|
|
|
ChrisElston wrote: I always try to work out everything the user could possibly do wrong, and code to catch it.
I consider that approach to be bad, security wise. Trying to prevent wrong behaviour/data is a flawed strategy and far too frequently fails. A better approach is to only accept know good behaviour/data. Yes, sometimes some good behaviour/data may be blocked but bad behaviour/data will almost certainly also be blocked.
|
|
|
|
|
Isn't it the same thing?
Only this is allowed = everything but this isn't allowed.
Every man can tell how many goats or sheep he possesses, but not how many friends.
|
|
|
|
|
No, it is not.
know bad as in "I always try to work out everything the user could possibly do wrong"
know good != not know bad
|
|
|
|
|
I think I may have explained myself poorly originally.
By everything the user could do I meant all the points in the UI where they enter something rather than all the possible data they could possibly enter.
Basically what I was trying to say was don't assume you know everything a user will try to do.
Every man can tell how many goats or sheep he possesses, but not how many friends.
|
|
|
|
|
I'll have to agree with Pedro.
Say the user ID should not accept spaces or special characters, so you code something to block all spaces and special characters of standard languages.
That will work until you get a Chinese user. Your database is not prepared to accept unicode data and there you go, your application just broke.
Now, if you coded in the first place to accept only [a-z], [A-Z] and [0-9] characters, the chances to fail that validation would disappear.
So yes, there is a difference between allowing the valid and disallowing the invalid. It has a different perspective. Even worse, imagine having to take into account all alphabets from all cultures.
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson
----
Our heads are round so our thoughts can change direction - Francis Picabia
|
|
|
|
|
They say things like:
"It worked on my machine"
"That's not how you described it"
"That wasn't specified"
"Its not my fault, blame the [insert guilty party]" , e.g. "Spec", "Testers", "Users" .
|
|
|
|
|
beat me to it 
|
|
|
|
|
I use defensive programming;
-by proper unit testing while developing a particular module.
-by proper comment lines (for behavior of respective function/ method) and regions.
and of course, meaningful naming conventions (by which one should easily come to know what's its use) all over in application.
|
|
|
|
|
Apart of Unit Testing, everything on your list is mere maintenance best practices.
Comments and naming conventions won't do any good to your software upon an unexpected input or if it needs to scale.
|
|
|
|
|
One of the principals of testing is to ensure whether a function is robust.
A function is made robust through means of defensive programming.
To the people that doesn't understand what defensive programming is:
An simple example:
bool increment_by_one(unsigned int32* input1)
{
bool status = FALSE;
if (input1 != NULL)
{
*input++;
status = TRUE;
}
else
{
status = FALSE;
}
return status;
}
"Program testing can be used to show the presence of bugs, but never to show their absence."
<< please vote!! >>
modified 14-May-12 5:02am.
|
|
|
|
|
I don't know about it, In the environment I work is to progressive and need fast and prompt development that, We can think of defense.
Read the subject line again.... Its an attack on the defensive programming (what ever it is).
|
|
|
|
|
Why would you want to attack something when you don't have an idea what it is?
Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
|
|
|
|
|
Because that is the natural human reaction.
"What is it?"
"I don't know"
"Let's kill it"
Every man can tell how many goats or sheep he possesses, but not how many friends.
|
|
|
|
|
I thought the natural human reaction was to "poke-it-with-a-stick":
ChrisElston wrote: "What is it?"
"I don't know"
"Let's kill it" "Let's poke it with a stick."
Jack of all trades ~ Master of none.
|
|
|
|
|
|
JOAT-MON wrote: I thought the natural human reaction was to "poke-it-with-a-stick"
Isn't it to say that God made it this way?
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson
----
Our heads are round so our thoughts can change direction - Francis Picabia
|
|
|
|
|
..and yes of course I am an human 
|
|
|
|
|
I had a boss at one time like that. His code constantly crashed in production. It took the team over month with overtime, to fix one of his projects that he developed, using his leet and fast programming skills.
|
|
|
|
|
|
Which means you're permanently drunk and can't read the subject? 
Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
|
|
|
|
|
Are you a students of english?
|
|
|
|
|
Yes,but i english is bad,Please forgive me.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
