一点ASP问题、差错和个人心得

关注

原创最新推荐文章于 2026-04-04 12:10:24 发布 1.0k 阅读 AI 写同款· GEO 优化 ›

ASP服务性规范考试周日，小A正和女朋友在逛街；于是，小A将华为研发小C（小A大学同学）的手机号码告诉小B，让小B找小C帮忙解决。小L到客户现场交付安装服务。工程师小A在现场处理故障需要重启服务器，由于服务器是主备用，客户认为有安全保障，要求在工作时间进行操作，小A认为客户既然已口头要求，可以进行操作。客户埋怨某产品的功能与华为销售宣讲的不一样，正在现场服务的工程师小A为了满足客户需求，自行帮助客户开通了该功能。现场服务工程师小A完成故障排除后，客户随工老B这时不在现场，小A找到另一客户工程师在现场服务报告上签字后离开。阅读详情

一点ASP问题、差错和个人心得

转贴自：http://www.5d.cn/bbs/NewsDetail.asp?id=917831

1.省略dim，方便但也是隐患！
申请变量后再使用是标准方法：
dim a
a = "1"
事实上，你不写dim也可以：
a = "1"
系统并不认为出错，它会自动判断a是不是一个已经存在的变量，存在就继续执行，如果不存在就自动帮你申请！看似系统好聪明好智能好体贴，但是隐患出来了！系统知道我的意思吗？系统很可能自作聪明，好心帮倒忙!问题一：如果我前面已经申请了一个变量，比如administrator，后面我要给这个变量赋值，我不幸写错了个字母或少写了个字母，比如administratar = “me"，系统终于等来了个“帮”我的机会，并“自告奋勇”的为我申明变量，“体贴周到”难以言表！是的，程序也许能运行，但逻辑上已经乱成一片了，因为系统没有报错（或者报了个其他错来误导你），你根本不能很快定位到问题处，如果程序很大，你花了很多时间找到根源后，你感想如何？你肯定很想骂系统“自做多情”，如果当初系统报一个administratar变量名不存在，我很快就能知道自己拼写错了，而把问题迅速纠正，而不必“沉醉”在系统的“自做多情”当中！省略dim后带来的另一个隐患后面会讲！

2.函数内申明的变量不会干扰外部的变量！
比如：
<%@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>"
%>

结果显示函数内部申明的变量是不会干扰外面的，它的作用域就是函数内部，其实学过其他语言的都应该知道！但要先声明，如果把函数内的dim a去掉的话，那就把那个a认为是外部的a，结果就变了！文件里面申请的变量，他的作用域就是这个文件。

3.让人又爱又恨的include！
include可以使ASP程序更加结构清晰，而且一些常用的函数可以被其他文件所共享！他带来的好处同时你必须注意缺点！
现在回到第一点谈到的省略dim，前面讲的是我赋值却被系统“好心”的变成了申明变量。现在讲的正好相反，我想声明变量，系统却赋值，因为省略dim也能申明变量，对于能省则省喜欢精简的程序员来说，常常挡不住这个诱惑（我有时候也喜欢这么申请，嘿嘿）但是，你能保证你申请的变量名前面的程序里没有？如果前面有这个变量名，那你不是申请成了赋值了？同一个文件中也许很少会犯这个错误，但是别忘了include，他是包含进来文件，如果包含进来的文件中有你申请的变量，那你就完了，就算能运行，逻辑上已经成问题了。如果你不偷懒，用dim申请，报错的时候，你幸运的得知这个变量名已经存在了！很快就能改正！

现在来讨论更复杂的情况，如果你include两个文件进来，在这两个文件中都有同一个变量名，如果两个都用dim申请的话，还好，就只是报错，说变量名已经存在了，很快就能知道问题了。现在你可以理解我为什么讲第二点的作用域了，由于作用域，不同文件同名变量一般情况下不会“打架”。但是，如果被另一个文件同时include进来，问题就麻烦了，所以如果你写的asp文件是准备被包含的，请防止同名的情况发生。再回到原来的讨论，如果两个include文件中申请同名变量都dim还好，但是后包含文件是用省略dim申请，问题就来了，后面的省略dim申请成赋值了，要命的是，这是在两个include文件中，很隐蔽，查找问题更困难！

综上所述，大家可以写一些简单的例子来体会体会其中的问题，最后建议：
1.变量请先用dim申请再使用！尤其多人开发的复杂程序！
2.给变量赋值请注意变量拼写！
3.仔细了解include的文件。

***现在讲讲查错：

事实上，寻找问题比代码编写更重要！我个人经验，问题分三类：
1.报错类，编译系统在编译系统过程中遇到的问题，它会给出错误信息，这是程序员最喜欢的问题，呵呵，不是变态，而是这种问题查起来最简单！

2.逻辑类，比较讨厌的问题，程序编译成功，也能运行，不过显示的结果不是你逻辑中期望的结果。oh, my god！怎么办，没有提示信息，只能凭经验和感觉去分析错误的结果，然后查源代码，顺利的话，几分钟解决，难缠的一天下来也没结果！

3.性能类，很可怕的问题，程序编译成功，也能正常运行，显示也正常！但是，偶尔隔段时间给你来个错误，你根本不知道错误是在什么情况下触发的，或者程序性能不如同类程序的高，运行慢，这些问题，有些一个星期一个月能解决了，有的几乎就是顽疾，治不好。我就曾经被这种问题折腾的死去活来！

所以，要想学好编程，就要尝试自己解决问题，尤其象ASP程序，逻辑方面出问题的情况不大，出的问题基本都是报错类的，有出错信息，出错位置，自己分析分析应该不难解决。我看有些人愿意在论坛上花个三天等别人告诉自己问题，为什么自己不去解决呢？自己查到一个问题，就长了一分经验，这才是程序员的财富！

***一点程序员的心得：
不要以为能写几行代码，做过几个小程序就以为是程序员了，等你去软件公司干上几年你就明白什么叫程序员了，编写代码不算什么，代码查错，优化代码，编写软件文挡（不是一个简单的用户手册，而是项目申请书，项目初步设计说明书，项目详细设计书，数据库设计说明书，项目测试说明书，用户使用手册，用户维护手册等等），事实上你会程序设计，并不代表你能软件开发。事实上我在某些方面还做的不够好，比如编写软件文档，呵呵，想想是件很恐怖的事情，编写软件文档比写程序痛苦多了！自己做了三年delphi程序员，虽然离开公司的时候完成一个不错的软件项目。但还是感觉到自己不足，所以现在我还是不停的补充其他各个方面的技术，这个社会竞争已经很激烈了，你越不努力向上，你越努力向失业靠近！

对于第一个问题，我强烈建议大家使用变量前用Dim定义一下，多写一行代码并不是很困难的事。然后在ASP文件头部用<%Option Explicit%>，这样，如果不小心把变量名写错，就会返回变量没有定义的错误，就可以很容易地查出错误位置，否则，该变量就是一个Null值。

另外，结合Option Explicit说一下第二个问题。有时候我们需要包含多个文件（比如head定义、顶部导航等代码），而Option Explicit在一个ASP Application（注意这里是说application,特指一次应用，而不是page，不表示一个页面）只能用一次。所以，Option Explicit最好不要放在include文件内部，以免被多个页面多次调用引起混乱。

再说一个关于 include 的小问题。一般，如果需要包含的文件就在当前目录内，我们可以直接用

来包含它。但是，很多时候我们有N个需要包含的文件。于是，为了方便管理，我们将它们统一放在一个INC或include目录内。这样，有时候包含代码就写成了：

这就是我要讨论的问题。请注意，使用..可以访问上层目录，由于而带来一个安全隐患：用户有可能非法引用站点外部文件。基于这个理由，Microsoft 发布的 IIS Lockdown 工具屏蔽了这个引用方法，并且 Microsoft 在 Windows Server 2003 的 IIS6.0 上默认是屏蔽这种方式的。对于这种不在本目录内的包含文件，推荐使用这种安全的引用方法：

欢迎更多有益的探索和讨论

收录于