1. Dim을 생략하는 것은 편리하지만 숨겨진 위험도 있습니다!
변수를 적용한 다음 이를 사용하는 것이 표준 접근 방식입니다.
어둡게 하다
a = "1"
실제로, Dim을 작성하지 않고도 이를 수행할 수 있습니다.
a = "1"
시스템은 오류가 있다고 생각하지 않습니다. a가 기존 변수인지 자동으로 확인하고, 존재하지 않으면 자동으로 적용됩니다. 시스템이 너무 스마트하고 똑똑하고 배려심 깊은 것 같지만 숨겨진 위험이 있습니다! 시스템은 내가 의미하는 바를 알고 있나요? 시스템이 너무 똑똑해서 도움이 안 될 가능성이 매우 높습니다! 질문 1: 관리자 등 이전에 변수를 신청했는데 나중에 이 변수에 값을 할당하고 싶은 경우, 불행하게도 문자를 잘못 썼거나 놓쳤습니다. 관리자 = "나"와 같은 편지, 시스템은 마침내 나를 "도움"할 기회를 기다렸고 나를 위해 변수를 선언하기 위해 "자원"했습니다. 얼마나 "사려 깊었는지" 표현하기 어렵습니다. 예, 프로그램은 실행될 수 있지만 논리가 엉망입니다. 시스템이 오류를 보고하지 않기 때문에(또는 오해할 수 있는 다른 오류를 보고하기 때문에) 프로그램이 크면 문제를 빨리 찾을 수 없습니다. 많은 시간을 들여 근본 원인을 찾는 데 많은 시간을 투자한 후의 기분은 어떻습니까? 당신은 분명히 시스템이 "자기 동기 부여"되어 있다고 꾸짖고 싶을 것입니다. 시스템이 관리자 변수 이름이 존재하지 않는다고 보고하면 나는 철자가 틀렸다는 것을 곧 알게 될 것이고 "빠져들지" 않고 신속하게 문제를 수정할 것입니다. 시스템의 "자동으로 "열정을 가져라"! Dim 생략으로 인한 또 다른 숨겨진 위험은 나중에 논의하겠습니다!
2. 함수 내에서 선언된 변수는 외부 변수를 방해하지 않습니다!
예를 들어:
< %@LANGUAGE="VBSCRIPT " CODEPAGE="936"%>
<%
어둡게 하다
a = "1"
함수 getstr()
어둡게 하다
a = "2"
함수 응답 종료
. & "<br>" 쓰기
getstr()
응답. & "<br>" 쓰기
%>
결과는 함수 내부에 선언된 변수가 외부 세계를 방해하지 않는다는 것을 보여줍니다. 사실 다른 언어를 공부한 사람이라면 누구나 알 것입니다! 그러나 함수 내의 희미한 a가 제거되면 a는 외부 a로 간주되고 결과가 변경된다는 점을 먼저 언급해야 합니다! 파일에 적용되는 변수의 범위는 이 파일입니다.
3. 좋아하기도 하고 미워하기도 하는 인클루드!
include는 ASP 프로그램의 구조를 더 명확하게 만들 수 있으며 일반적으로 사용되는 일부 기능을 다른 파일에서 공유할 수 있습니다! 장점도 있지만 단점에도 주의를 기울여야 합니다!
이제 첫 번째 지점에서 언급한 희미한 생략으로 돌아가서, 앞서 언급한 것은 내 할당이 시스템에 의해 선언된 변수로 "친절하게" 바뀌었다는 것입니다. 지금 제가 말하는 것은 정반대입니다. 변수를 선언하고 싶은데, 희미함을 생략해도 변수 선언이 가능하기 때문에 시스템에서 값을 할당해 주는 것입니다. 이런 유혹을 참지 못하는 경우가 많습니다(저도 가끔 이런식으로 적용하고 싶습니다. , ㅎㅎ) 그런데, 신청한 변수명이 이전 프로그램에 없다는 걸 보장해주실 수 있나요? 앞에 이 변수명이 있으면 과제를 신청했다는 뜻 아닌가요? 이 실수는 동일한 파일에서 거의 발생하지 않지만 포함된 파일이라는 점을 잊지 마십시오. 포함된 파일에 적용한 변수가 포함되어 있으면 실행이 가능하더라도 이미 문제가 있는 것입니다. 논리적 문제. 게으르지 않고 희미한 적용을 사용하면 오류가 보고될 때 이 변수 이름이 이미 존재한다는 것을 알게 되면 운이 좋을 것입니다! 곧 수정될 예정입니다!
이제 더 복잡한 상황에 대해 논의해 보겠습니다. 두 개의 파일을 포함하면 두 파일 모두에 동일한 변수 이름이 있게 됩니다. 두 파일 모두에 적용하기 위해 Dim을 사용하면 변수 이름이 이미 존재한다는 오류만 보고됩니다. , 곧 문제를 알게 될 것입니다. 이제 범위의 두 번째 지점에 대해 이야기한 이유를 이해할 수 있습니다. 범위로 인해 다른 파일에 있는 동일한 이름을 가진 변수는 일반적으로 "싸움"하지 않습니다. 다만, 다른 파일에 동시에 포함되어 있는 경우에는 문제가 발생하므로, 작성하신 ASP 파일을 포함시키려는 경우에는 같은 이름의 사태가 발생하지 않도록 주의하시기 바랍니다. 원래 논의로 돌아가서 두 개의 포함 파일에 적용할 때 동일한 이름을 가진 두 개의 포함 변수가 모두 희미하면 문제가 없지만, 이후에 생략된 희미한 응용 프로그램을 생략하여 나중에 포함된 파일을 적용하면 문제가 발생합니다. 끔찍한 점은 이것이 두 개의 포함 파일에 포함되어 있어 매우 숨겨져 있어 문제를 찾기가 더 어렵다는 것입니다.
요약하자면, 문제를 이해하기 위해 몇 가지 간단한 예를 작성할 수 있습니다.
1. 변수를 사용하기 전에 먼저 Dim을 이용하여 변수를 신청해주세요! 특히 여러 사람이 개발하는 복잡한 프로그램!
2. 변수에 값을 할당할 때 변수의 철자법에 주의해주세요!
3. 포함 파일을 주의 깊게 이해하십시오.
***이제 오류 검사에 대해 이야기해 보겠습니다.
사실 코드를 작성하는 것보다 문제를 찾는 것이 더 중요합니다! 내 개인적인 경험에 따르면 문제는 세 가지 범주로 분류됩니다.
1. 오류 보고 유형은 시스템의 컴파일 과정 중에 컴파일 시스템에서 발생하는 문제로, 오류 메시지를 표시합니다. 이것은 프로그래머가 가장 좋아하는 문제입니다. 하하, 비정상은 아니지만 이런 종류의 문제가 있습니다. 가장 쉽게 확인할 수 있습니다!
2. 다소 짜증나는 문제인 논리 유형. 프로그램이 성공적으로 컴파일되어 실행될 수 있지만 표시된 결과는 논리에서 예상한 결과가 아닙니다. 맙소사! 프롬프트 메시지가 없습니다. 경험과 느낌에 따라 오류 결과를 분석하고 소스 코드를 확인하면 몇 분 안에 해결됩니다. 힘든 하루를 보낸 결과!
3. 성능 카테고리, 끔찍한 문제입니다. 프로그램이 성공적으로 컴파일되었고 정상적으로 실행되었으며 정상적으로 표시됩니다! 그러나 가끔씩 오류가 발생하고 어떤 상황에서 오류가 발생하는지 알 수 없거나 프로그램 성능이 유사한 프로그램만큼 높지 않고 느리게 실행되는 경우 이러한 문제 중 일부는 내에서 해결될 수 있습니다. 일주일, 한 달 안에 해결되는 경우도 있고, 대부분은 치료가 불가능한 고질병이다. 나는 이런 문제로 고문을 받아 죽었습니다!
그러므로 프로그래밍을 잘 배우고 싶다면 스스로 문제를 해결해 보아야 합니다. 특히 ASP 프로그램처럼 로직에 문제가 많지는 않습니다. 발생하는 문제는 기본적으로 오류 메시지와 오류 위치가 있습니다. 스스로 해결하기 어려워서 분석할 필요는 없습니다. 어떤 사람들은 다른 사람들이 자신의 문제를 스스로 해결하기를 기다리며 포럼에서 3일을 기꺼이 보낼 것 같습니다. 스스로 문제를 발견하면 경험을 쌓게 될 것입니다. 이것이 바로 프로그래머의 재산입니다!
***약간의 프로그래머 경험:
단지 몇 줄의 코드를 작성할 수 있거나 몇 가지 작은 프로그램을 수행했다고 해서 자신이 프로그래머라고 생각하지 마십시오. 소프트웨어 회사에서 몇 년 동안 일한 후에는 프로그래머가 된다는 것이 무엇을 의미하는지 이해하게 될 것입니다. 코드 작성은 코드 오류 검사 및 최적화에 지나지 않습니다. 코드, 소프트웨어 문서 작성(간단한 사용자 매뉴얼이 아니라 프로젝트 애플리케이션, 프로젝트 예비 설계 지침, 프로젝트 세부 설계 지침, 데이터베이스 설계 지침, 프로젝트 테스트 지침, 사용자 매뉴얼, 사용자) 유지보수 매뉴얼 등), 사실 프로그래밍을 할 수 있다고 해서 소프트웨어를 개발할 수 있는 것은 아닙니다. 사실 저는 소프트웨어 문서 작성과 같은 어떤 면에서는 부족합니다. 하하, 소프트웨어 문서를 작성하는 것은 프로그램을 작성하는 것보다 훨씬 더 고통스럽습니다. 나는 회사를 떠날 때 좋은 소프트웨어 프로젝트를 완료했지만 3년 동안 델파이 프로그래머로 일했습니다. 하지만 아직은 부족하다고 느껴서 지금은 계속해서 다른 면에서 기술을 추가하고 있습니다. 이 사회의 경쟁은 이미 매우 치열할수록, 열심히 일할수록 실업에 가까워집니다!
첫 번째 질문에 대해서는 변수를 사용하기 전에 Dim을 사용하여 변수를 정의하는 것이 좋습니다. 코드를 한 줄 더 작성하는 것은 그리 어렵지 않습니다. 그런 다음 ASP 파일의 헤더에 <%Option Explicit%>를 사용하면 실수로 변수 이름을 잘못 썼을 경우 변수가 정의되지 않았다는 오류가 반환되고 오류 위치를 쉽게 찾을 수 있습니다. 그렇지 않으면 변수는 Null 값입니다.
그리고 Option Explicit와 연계하여 두 번째 질문에 대해 이야기해보겠습니다. 때로는 여러 파일(예: 헤드 정의, 상단 탐색 및 기타 코드)을 포함해야 하며 Option Explicit는 ASP 응용 프로그램에서만 사용할 수 있습니다. 여기서는 응용 프로그램을 나타내며 특히 페이지가 아닌 응용 프로그램을 나타냅니다. 페이지를 의미하지 않음) 한 번. 따라서 여러 페이지에서 여러 번 호출되어 발생하는 혼란을 피하기 위해 Option Explicit를 포함 파일 내에 배치하지 않는 것이 가장 좋습니다.
포함에 관한 작은 질문에 대해 이야기합시다. 일반적으로 포함할 파일이 현재 디렉터리에 있으면 직접 사용할 수 있습니다.
<!--#include file="abc.asp"-->
이를 포함합니다. 그러나 포함해야 할 파일이 N개 있는 경우가 많습니다. 따라서 관리를 용이하게 하기 위해 INC에 넣거나 디렉터리를 포함합니다. 이러한 방식으로 때로는 포함 코드가 다음과 같이 작성됩니다.
<!--#include file="..incabc.asp" -->
이것이 제가 논의하고 싶은 내용입니다. ..를 사용하면 상위 디렉터리에 접근할 수 있어 보안상 위험할 수 있으니 주의하세요. 사용자가 사이트 외부의 파일을 불법적으로 참조할 수 있습니다. 이러한 이유로 Microsoft에서 출시한 IIS 잠금 도구는 이 참조 방법을 차단하며 Microsoft는 Windows Server 2003의 IIS6.0에서 기본적으로 이 방법을 차단합니다. 이 디렉터리에 없는 포함된 파일의 경우 다음과 같은 안전한 참조 방법을 사용하는 것이 좋습니다.
<!--#include virtual="/inc/abc.asp"-->
더 유용한 탐색과 토론을 환영합니다.