|
How much defense do you put in an object with a single responsibility, keeping in mind that you're not even allowed to throw exceptions that are not thrown by the base class?
The examples on the wiki are ridiculous; parameter-checking is a general best practice. Yes, sometimes you implement a strategy-pattern as a way of "extending" the application later on.
I'm following an idea from PHP; do, or die. If the code encounters anything exceptional, an exception is raised. If it's an unexpected exception, the app will terminate. It has to, since I can't guarantee that it's data isn't corrupted at that point.
Bastard Programmer from Hell
|
|
|
|
|
Almost no defensive programming... except if it makes my code crash sooner. (so I can find the problem more easily)
I also add some defensive programming if a poor crash description wasted my time once.
I'm more reactive that preemptive. But I always make sure that nor me, nor someone else will waste time again on the same problem.
|
|
|
|
|
Mainly to offend people who have different ideas than mine about how the program should be used.
modified 18-May-12 7:34am.
|
|
|
|
|
So V has morphed into a manager, poor bastard has to try and think of acceptable way of presenting crap ideas without spitting out buzzwords, defensive programming indeed!
V be a man, put your balls on the line and call it future proofing !BANG!...
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
defensive programming is anethema to speeeeeeeeeeeeeeed.
m.bergman
For Bruce Schneier, quanta only have one state : afraid.
To succeed in the world it is not enough to be stupid, you must also be well-mannered. -- Voltaire
In most cases the only difference between disappointment and depression is your level of commitment. -- Marc Maron
I am not a chatbot
|
|
|
|
|
Well, at least your program will be fast when it crashes and burns.
|
|
|
|
|
That burning smell is not my program crashing, it's my program burning through your cpu.
m.bergman
For Bruce Schneier, quanta only have one state : afraid.
To succeed in the world it is not enough to be stupid, you must also be well-mannered. -- Voltaire
In most cases the only difference between disappointment and depression is your level of commitment. -- Marc Maron
I am not a chatbot
|
|
|
|
|
As the in-house coder for my firm, I get asked to do a lot of ad hoc stuff, once-off applications meant to fulfil an immediate need and then never used again.
In those cases, I don't bother writing defensively. I will, however, put in an expiration date: if the application is run after that date, the app turns into nagware that reminds the user that it has expired. That is usually enough to get the user to rethink using the app, and maybe asking me to redesign it for long-term use.
|
|
|
|
|
I've seen screwdrivers being used as hammers so setting arbitrary limits on things that don't need limits ensures something will fail catastrophically at some future date.
It happens no matter how well you try to document the functionality. If a tool is there, it will be used in grossly inappropriate ways at some point in its existence thanks to project managers who don't know what they need and programmers who can't program[^].
|
|
|
|
|
I'm not sure which is the chickens and which is the eggs, but
I consider the user as the enemy and must therefore code defensively against their mindless assaults.
or, I program defensively because the user is the enemy.
Which both sound kinda like the same thing - it's a cause/effect thing - and definitely recursive.
There's also the berserker class, i.e., management.
Q.V.: Albert Einstein quote (below).
"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 |
|
|
|
|
|
|
Same for me and in C++, I also use compile time checking in some cases. For exemple, if the code is hardcoded for the case a constant has a given value (maybe to be more efficient), I would do a compile time check so that if the constant is changed, it would raise a compile time error...
Philippe Mori
|
|
|
|
|
Programming defensively for sane users are fun.
Programming defensively for stupid users is just tiresome.
-
Just that something can be done, doesn't mean it should be done. Respect developers and their efforts!
Jk
|
|
|
|
|
Jyothikarthik_N wrote: Programming defensively for stupid users is just tiresome.
My world: welcome to it.
|
|
|
|
|
Jyothikarthik_N wrote: Programming defensively for stupid users is just tiresome.
In India, you have people trying hard to break any system you give them.
Thay are not stupid. They are intelligent.
It is their way of rebelling against the system.
There are three kinds of systems: fool-proof, idiot-proof and elephant-up proof.
India is the world's laboratory for elephant-up proofing anything. Sort of like the Underwriters Laboratory in the US.
An example.
Here in Chennai, the Outsourcing Capital of the World, the Municipal Corporation computerized the property payment system.
Inexplicably, the computerized system assigned number 162-0000-025 to my friend's house. The previous number was 162-0000-000.
The guy who took in the payment of the property tax, struck out the 025 and put in 000 - the old number - and tried to apply the payment. The system moved it to "Suspense Account". This went on for 4 years. It has taken countless visits to an overcrowded central office to try to resolve the issue. My friend is out at least one tax payment.
It is a good thing that 000 was not assigned to someone else. Then my friend would have been paying somebody else's property tax and the Municipal Corporation would cheerfully have told her to contact the other person and get the money back!
modified 19-May-12 2:35am.
|
|
|
|
|
But most of the times I leave this "small bugs" to fix later, when the client needs and pays for it..
OFC I never leave "system-critical small bugs".
|
|
|
|
|
A few people weren't too sure what it means, so to clarify:
Like defensive driving - always assume the worst is waiting to happen. Yes, it makes you slower, and it may be less fun, but you arrive in one piece with a low adrenalin level. I never bent a single fender, whereas the spousal unit has scrapped three (THREE!) cars because of his aggressive driving style.
~~~~~~~ <;,>< ~~~~~~~~~~~
|
|
|
|
|
When you're doing a spike, you don't want to care about anything else.
|
|
|
|
|
here in Asia "Agile Development" pretty much equates to "Broken underfunded projects delivered in 2 months" and we're very god damn agile here in Asia, can't really afford *defensive* things. Embrace risk, code offensively! Amen!
dev
|
|
|
|
|
I like your attitude, are you looking for a job?
~~~~~~~ <;,>< ~~~~~~~~~~~
|
|
|
|
|
Built-in: i choose to use C#. The choice is defensive, and works. Think: Visual Studio.
OTOH, a current project in VBA required me to build all KINDS of my own fences, error processing, and tracing mechanisms merely to maintain a sane environment. Given a choice, i will choose anything other than VBA, up to and including refusing the project.
Grace + Peace
Peter N Roth, President
http://engineeringobjects.com
|
|
|
|
|
The choice of language is, to an extent, irrelevant in my opinion.
Consider what happens if you ask a user there age and they input "Apples".
Without defensive coding you've got a bug.
Even if the user inputs an integer, not all are valid or meaningful. An age of -20 makes no sense. An age of 256 is unlikely.
|
|
|
|
|
Ah! See, I was thinking defensive programming would protect ME, whereas other responders are looking to protect the SOFTWARE. To hell with it, I say; it’s just a machine… but choosing the right language (whichever one keeps you most safe) is crucial. Type safety, garbage collection, Object Oriented, etc.
Grace + Peace
Peter N Roth, President
http://engineeringobjects.com
|
|
|
|
|
|
The best defensive code is the use of 'not equal to' in any comparison test.
|
|
|
|