|
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.
|
|
|
|
|
I guess I don't quite know what defensive programming is then...
A few things that I think are good defensive programming practices are...
1. NULL checks on pointers.
2. Limited use of stack buffers, and bounds checking when used...
3. Use the const operator for reference passing, to avoid accidental writes to objects.
4. Comments when the operation of a method is opaque.
5. Make data members protected or private unless there is a good reason not to.
6. Make all unsafe methods protected or private. If they need an interface, make a public one that provides some validation of the inputs.
I've been criticized by some in using const references to pass objects. I'm told it's an optimization. Instead, I should copy objects on the stack by default. But that seems to me, to be bloatization, as a default reference point. It certainly can bring a server to it's knees if it's used as the default practice.
|
|
|
|
|
Kinda surprised at the people that say they don't know how the code will be used or writing secure code.
I see defensive coding as following a set pattern of tests before accessing an object:
Is it null when it shouldn't be?
Is it of the proper format expected?
Am I trapping possible exceptions?
Am I logging those exceptions and returning a message?
Basically defensive programming is making sure that in spite of usage that nothing will cause the unexpected exception window to pop up and stop the application from running.
|
|
|
|
|
...so I arrange the code to work anyway.
Veni, vidi, vici.
|
|
|
|
|
From the wikipedia entry it seems "defensive programming" is more about avoiding security holes (buffer overflows, etc.). "continuing function of a piece of software in spite of unforeseeable usage of said software" is a bit vague. To me that sounds like using a spreadsheet program to do video editing.
|
|
|
|
|
In general, it is good to follow basic defensive programming rules, as long as:
1) Software does not slip in an undefined state when you have no idea what it is doing any more.
2) Data does not get corrupted.
I believe it is much better to crash on the spot than hit either 1) or 2).
|
|
|
|
|
Ok, we're talking about software here aren't we?
So what can be less foreseeable than developing a piece of code?
At the time of development you may have an absolute idea of what it is meant to do, and with a strict data input but it will most certainly change.
It may take a day, a month, a year but if the software itself lives, your code will have to handle some "unexpected" scenarios, and this is where your "defense" will be put to the test.
Business change, people change, everything change, so every piece of code you do must adapt even if by just handling the errors and reporting them correctly to the IT dep.
To be prepared for errors won't consume more development time if its implemented by design. Think about it right from the beginning and it will feel natural to use, not an hack.
|
|
|
|
|
Hmm, if you do this for a living you work to a written and agreed specification. If the customer changes his mind or wants more (they always do) he has to write it down, agree the details with you and, of course, give you more money.
You can never guess in advance all the things that can go wrong, though after a few years you get a pretty good idea, and do things like checking input data even if you sent it yourself from the previous module. If you know your customer you can anticipate future changes and put comments in - "comment this bit back in for southern hemisphere".
~~~~~~~ <;,>< ~~~~~~~~~~~
|
|
|
|
|
You're right.
Like you said, customers change their mind, either because they just do or because the business itself did, but things change despite its written on a 1000 sheet spec or not.
At the end of the day the customer wants it changed, even agreeing to pay for it, it's up to you to decide how hard it will be for you .
So what I think is that the software we write must be prepared to handle change in more way than just the user input, we also must prepare it for business change, for scalability, extensibility, etc...
Usually this doesn't mean a whole bunch of extra work, specially if it's design that way right from the beginning.
If the design is right you can start to think about software changes as a way of earning extra money instead of just loosing it!
|
|
|
|