| |
Fei Nage dynamic inverse law:
Go wrong, will go wrong eventually - at the worst possible moment.
Defensive programming (Defensive Programming) What does it mean
Defensive programming, simply put, it is when programming purposefully predict possible points of failure. It aimed at those issues that may occur prior to the occurrence of solving them. You see the problem, right? Prediction unexpected things do have inherent difficulty of forecasting when you want something unexpected and even more difficult to solve it on several times.
Let's look at a few practical examples.
Conditional statements
This is easily one of the most defensive programming, and is the easiest place to meet. In many cases, programming with PHP you will not need "else".
Suppose you need to write a function and a conditional statement. Here, you only need to use three conditional statements for your specific variables as follows:
if ($ var == a) {}
elseif ($ var == b) {}
elseif ($ var == c) {}
There is no other possibility, you say, and continue code code. But let us pause here. I know you know there are no other possibilities of. And I believe you. But sometimes (unpredictable) happens. We forget some things. We check for errors. We eventually reuse some code, beyond the original predetermined range. Suddenly we have sometimes silent disclose errors or error status, because we do not use catch. Using the else block. When using the switch to use the default. Use them to return or recording errors, so that you know what happened (If this happens then). Although it will use more than two lines of code, but you can not predict some of the things that occurs, it is worth it.
I can not believe that user input
Have you ever heard of this statement? Most programmers heard. This is a little vague, popular speak, of course. But it is the truth. You should never believe that user input. This does not mean you assume that all users are crazy hackers who use some carefully designed command to destroy your application. No need for paranoia. However, you should assume that you do not know your code, they do not know what you need to fill in parameters, or parameters should be long. They do not know what size or what file types can be uploaded (even if the application had told them). Occasionally, they would be a machine or a hacker and they want to run the script on their input, sometimes even after landing in the input. How do you know that you can trust or authentication codes can provide a secure fortress before the user input?
Answer: never.
You would never believe user input. If you trust user input, then you will never have a break. do you understand? So you always have to evaluate input, make sure you are dealing with the data to be stored in the database, especially when you want it displayed, or the use of appropriate technology. So - I do not believe the input, even if not from the local user input - input validation will always be your friend. See Survive the Deep End: PHP Security validation library and use it.
Suppose your code
Do not assume anything. If the first two relating to teach us anything, it is that we should not make any assumptions. As a programmer, especially after working on a project for too long, we started to do a lot of assumptions. We assume that the user knows some of the things we know. Is not necessarily the technical details, the program can also be functional details. We assume that the user knows how much can file since. . . We already know. Or they know that in order for the message script. . . It does not work, they do not know any of these things. This seems to be more of a front end of the work, it is clear that you still have to deal in the back-end user behavior and user input, it is worthwhile to think.
Many programmers will do another amazing is that we assume for significant functional properties of our functions, classes, or other piece of code at any time. A defensive programmer will carefully consider not only using a general document to describe the function is doing - they will also write down their input parameters, use cases, or any other similar things to make any assumptions . Because we are all human, we had a period of time will forget something. Finally, we are also likely to face other people to maintain, extend or replace our code. If nothing else, recall, programming takes place in a world full of technological change in. If your application can still be used for several years, you may upgrade PHP version and lose some function, or some of your own need to change the code inside have interaction between components. These are very difficult to predict, so good comments and documentation is very important. |
|
|
|