1. Omitting dim is convenient but also a hidden danger!
Applying a variable and then using it is the standard approach:
dim a
a = "1"
In fact, you can do it without writing dim:
a = "1"
The system does not think there is an error. It will automatically determine whether a is an existing variable. If it exists, it will continue to execute. If it does not exist, it will automatically apply for you! It seems that the system is so smart, smart and considerate, but there are hidden dangers! Does the system know what I mean? The system is very likely to be too smart and not helpful! Question 1: If I have applied for a variable before, such as administrator, and I want to assign a value to this variable later, I unfortunately write the wrong letter or miss a letter, such as administrator = "me ", the system finally waited for an opportunity to "help" me, and "volunteered" to declare the variables for me. It's hard to express how "considerate" it was! Yes, the program may be able to run, but the logic is messed up. Because the system does not report an error (or reports another error to mislead you), you cannot quickly locate the problem. If the program is large, you will spend a lot of time. How do you feel after spending a lot of time finding the root cause? You definitely want to scold the system for being "self-motivated". If the system reported that the administrator variable name did not exist, I would soon know that I had spelled it wrong and correct the problem quickly without having to "indulge" in the system's "automatic "Be passionate"! Another hidden danger caused by omitting dim will be discussed later!
2. Variables declared within the function will not interfere with external variables!
for example:
< %@LANGUAGE="VBSCRIPT " CODEPAGE="936"%>
<%
dim a
a = "1"
function getstr()
dim a
a = "2"
end function
response.Write a & "<br>"
getstr()
response.Write a & "<br>"
%>
The result shows that variables declared inside the function will not interfere with the outside world. Its scope is inside the function. In fact, everyone who has studied other languages should know this! But it must be stated first that if the dim a within the function is removed, then that a is considered to be an external a, and the result will change! The scope of the variables applied in the file is this file.
3. An include that makes people both love and hate it!
include can make the structure of the ASP program clearer, and some commonly used functions can be shared by other files! While it brings benefits, you must pay attention to the drawbacks!
Now back to the omission of dim mentioned in the first point. What I mentioned earlier is that my assignment was "kindly" turned into a declared variable by the system. What I'm talking about now is exactly the opposite. I want to declare a variable, but the system assigns it a value because it is possible to declare a variable even if dim is omitted. For programmers who like to save and simplify, they often cannot resist this temptation (I also like to apply like this sometimes. , hehe) But, can you guarantee that the variable name you applied for is not in the program before it? If there is this variable name in front of it, doesn't it mean that you have applied for assignment? This mistake may rarely be made in the same file, but don't forget include. It is an included file. If the included file contains the variables you applied for, then you are screwed. Even if it can run, it is already a logical problem. . If you are not lazy and use dim to apply, when the error is reported, you will be lucky to know that this variable name already exists! It will be corrected soon!
Now let’s discuss a more complicated situation. If you include two files, there will be the same variable name in both files. If you use dim to apply for both, okay, it will just report an error saying that the variable name already exists. , you will know the problem soon. Now you can understand why I talked about the second point of scope. Due to scope, variables with the same name in different files will generally not "fight". However, if it is included by another file at the same time, the problem will be troublesome, so if the asp file you write is intended to be included, please prevent the situation with the same name from happening. Going back to the original discussion, it would be fine if both include variables with the same name are dim when applied for in the two include files, but the problem arises if the later included file is applied by omitting dim. The subsequent omitted dim application becomes an assignment. The terrible thing is, this It is in two include files, which is very hidden, making it more difficult to find the problem!
To sum up, you can write some simple examples to understand the problems. Finally, I suggest:
1. Please use dim to apply for variables before using them! Especially complex programs developed by multiple people!
2. When assigning values to variables, please pay attention to the spelling of the variables!
3. Carefully understand the include files.
***Now let’s talk about error checking:
In fact, finding problems is more important than writing code! From my personal experience, problems fall into three categories:
1. Error reporting type, the problem encountered by the compilation system during the compilation process of the system, it will give an error message. This is the favorite problem of programmers. Haha, it is not abnormal, but this kind of problem is the easiest to check!
2. Logic type, a rather annoying problem. The program is compiled successfully and can be run, but the displayed result is not the result expected in your logic. Oh, my god! What should I do? There is no prompt message. I can only analyze the error results based on experience and feeling, and then check the source code. If everything goes well, it will be solved in a few minutes. However, there is no result after a difficult day!
3. Performance category, a terrible problem. The program was compiled successfully, runs normally, and displays normally! However, occasionally an error comes to you every once in a while, and you have no idea under what circumstances the error is triggered, or the program performance is not as high as similar programs and runs slowly. Some of these problems can be solved within a week or a month, and some can be solved within a week or a month. Most of them are stubborn diseases that cannot be cured. I have been tortured to death by this kind of problem!
Therefore, if you want to learn programming well, you must try to solve problems by yourself. Especially like ASP programs, there are not many problems with logic. The problems that occur are basically error reports. There are error messages and error locations. It should not be necessary to analyze them by yourself. Difficult to solve. I think some people are willing to spend three days on the forum waiting for others to tell them their problems. Why don't they solve it themselves? If you find a problem yourself, you will gain experience. This is the wealth of programmers!
***A little programmer’s experience:
Don’t think that you are a programmer just because you can write a few lines of code or have done a few small programs. After you work in a software company for a few years, you will understand what it means to be a programmer. Writing code is nothing but code error checking and optimization. Code, write software documentation (not a simple user manual, but a project application, project preliminary design instructions, project detailed design instructions, database design instructions, project test instructions, user manual, user maintenance manual, etc.), facts Just because you can program, it doesn't mean you can develop software. In fact, I'm not good enough in some aspects, such as writing software documentation. Haha, it's a scary thing to think about. Writing software documentation is much more painful than writing a program! I have been a Delphi programmer for three years. Although I completed a good software project when I left the company. But I still feel that I am insufficient, so now I continue to add skills in other aspects. The competition in this society is already very fierce. The less you work hard, the harder you work to get closer to unemployment!
Regarding the first question, I strongly recommend that you use Dim to define variables before using them. It is not very difficult to write one more line of code. Then use <%Option Explicit%> in the header of the ASP file. In this way, if you accidentally write the variable name incorrectly, an error that the variable is not defined will be returned, and the error location can be easily found. Otherwise, the variable is a Null value.
In addition, let’s talk about the second question in conjunction with Option Explicit. Sometimes we need to include multiple files (such as head definition, top navigation and other codes), and Option Explicit can only be used in an ASP Application (note that it refers to application here, specifically refers to an application, not page, and does not mean a page) once. Therefore, Option Explicit is best not to be placed inside the include file to avoid confusion caused by being called multiple times on multiple pages.
Let’s talk about a small question about include. Generally, if the file to be included is in the current directory, we can directly use
<!--#include file="abc.asp"-->
to include it. However, many times we have N files that need to be included. Therefore, in order to facilitate management, we put them in an INC or include directory. In this way, sometimes the include code is written as:
<!--#include file="..incabc.asp" -->
This is what I want to discuss. Please note that using .. can access the upper directory, which brings a security risk: users may illegally reference files outside the site. For this reason, the IIS Lockdown tool released by Microsoft blocks this reference method, and Microsoft blocks this method by default on IIS6.0 of Windows Server 2003. For such included files that are not in this directory, it is recommended to use this safe reference method:
<!--#include virtual="/inc/abc.asp"-->
Welcome more useful exploration and discussion