1. ¡Omitir la atenuación es conveniente pero también un peligro oculto!
Aplicar una variable y luego usarla es el enfoque estándar:
atenuar un
un = "1"
De hecho, puedes hacerlo sin escribir dim:
un = "1"
El sistema no cree que haya un error. Determinará automáticamente si a es una variable existente. Si existe, continuará ejecutándose. Si no existe, se aplicará automáticamente. Parece que el sistema es muy inteligente, inteligente y considerado, ¡pero hay peligros ocultos! ¿Sabe el sistema a qué me refiero? Es muy probable que el sistema sea demasiado inteligente y no sea útil. Pregunta 1: Si he solicitado una variable antes, como administrador, y quiero asignar un valor a esta variable más adelante, desafortunadamente escribo la letra incorrecta o me olvido de una. carta, como administrador = "yo", el sistema finalmente esperó una oportunidad para "ayudarme" y "se ofreció" a declarar las variables por mí. ¡Es difícil expresar lo "considerado" que fue! Sí, es posible que el programa pueda ejecutarse, pero la lógica es errónea. Debido a que el sistema no informa un error (o informa otro error para engañarlo), no podrá localizar rápidamente el problema. Pasa mucho tiempo ¿Cómo te sientes después de pasar mucho tiempo buscando la causa raíz? Definitivamente querrás regañar al sistema por "automotivarse". Si el sistema informara que el nombre de la variable del administrador no existe, pronto sabría que lo he escrito mal y corregiría el problema rápidamente sin tener que "entregarme". ¡El sistema "automático "Sé apasionado"! ¡Otro peligro oculto causado por omitir la atenuación se discutirá más adelante!
2. ¡Las variables declaradas dentro de la función no interferirán con las variables externas!
Por ejemplo:
< %@LANGUAGE="VBSCRIPT " CODEPAGE="936"%>
<%
atenuar un
un = "1"
función obtienetr()
atenuar un
un = "2"
de función final.
Escribe un & "<br>"
obtienetr()
respuesta.Escribe un & "<br>"
%>
El resultado muestra que las variables declaradas dentro de la función no interferirán con el mundo exterior. Su alcance está dentro de la función. De hecho, ¡todos los que hayan estudiado otros idiomas deberían saber esto! Pero primero debe decirse que si se elimina la a tenue dentro de la función, entonces esa a se considera una a externa, ¡y el resultado cambiará! El alcance de las variables aplicadas en el archivo es este archivo.
3. ¡Una inclusión que hace que la gente la ame y la odie!
incluir puede aclarar la estructura del programa ASP y algunas funciones de uso común pueden ser compartidas por otros archivos. Si bien trae beneficios, ¡debes prestar atención a los inconvenientes!
Ahora volvamos a la omisión de dim mencionada en el primer punto. Lo que mencioné anteriormente es que mi tarea fue "amablemente" convertida en una variable declarada por el sistema. De lo que estoy hablando ahora es exactamente lo contrario. Quiero declarar una variable, pero el sistema le asigna un valor porque es posible declarar una variable incluso si se omite dim. Para los programadores a quienes les gusta ahorrar y simplificar, lo hacen. A menudo no puedo resistir esta tentación (a veces también me gusta aplicar así, jeje). Pero, ¿puedes garantizar que el nombre de la variable que solicitaste no esté en el programa anterior? Si aparece este nombre de variable delante, ¿no significa que ha solicitado la asignación? Este error rara vez se comete en el mismo archivo, pero no olvide incluir. Es un archivo incluido. Si el archivo incluido contiene las variables que solicitó, entonces está jodido. Incluso si se puede ejecutar, ya es un archivo. problema lógico. Si no es vago y usa dim para aplicar, cuando se informe el error, tendrá suerte de saber que este nombre de variable ya existe. ¡Se corregirá pronto!
Ahora analicemos una situación más complicada. Si incluye dos archivos, habrá el mismo nombre de variable en ambos archivos. Si usa dim para aplicar para ambos, está bien, solo informará un error que indica que el nombre de la variable ya existe. , sabrás el problema pronto. Ahora puedes entender por qué hablé del segundo punto del alcance. Debido al alcance, las variables con el mismo nombre en diferentes archivos generalmente no "pelearán". Sin embargo, si lo incluye otro archivo al mismo tiempo, el problema será problemático, por lo que si el archivo asp que escribe está destinado a incluirse, evite que ocurra la situación con el mismo nombre. Volviendo a la discusión original, estaría bien si ambas variables de inclusión con el mismo nombre fueran atenuadas cuando se solicitaran en los dos archivos de inclusión, pero el problema surge si el archivo incluido posteriormente se aplica omitiendo la aplicación atenuada posterior. se convierte en una tarea. Lo terrible es que está en dos archivos de inclusión, lo cual está muy oculto, lo que hace que sea más difícil encontrar el problema.
En resumen, puede escribir algunos ejemplos simples para comprender el problema. Finalmente, sugiero:
1. ¡Utilice dim para solicitar variables antes de usarlas! ¡Programas especialmente complejos desarrollados por varias personas!
2. Al asignar valores a las variables, ¡preste atención a la ortografía de las variables!
3. Comprenda detenidamente los archivos incluidos.
*** Ahora hablemos de la comprobación de errores:
de hecho, ¡encontrar problemas es más importante que escribir código! Desde mi experiencia personal, los problemas se dividen en tres categorías:
1. Tipo de informe de error, el problema encontrado por el sistema de compilación durante el proceso de compilación del sistema dará un mensaje de error. Este es el problema favorito de los programadores Jaja, no es anormal, pero este tipo de problema es. ¡Más fácil de comprobar!
2. Tipo de lógica, un problema bastante molesto. El programa se compila correctamente y se puede ejecutar, pero el resultado mostrado no es el resultado esperado en su lógica. ¡Ay dios mío! ¿Qué debo hacer? No hay ningún mensaje de aviso. Solo puedo analizar los resultados del error según la experiencia y los sentimientos, y luego verificar el código fuente, si todo va bien, se resolverá en unos minutos. resultado después de un día difícil!
3. Categoría de rendimiento, un problema terrible. ¡El programa se compiló correctamente, se ejecuta normalmente y se muestra normalmente! Sin embargo, ocasionalmente aparece un error de vez en cuando y no tiene idea de en qué circunstancias se activa el error, o el rendimiento del programa no es tan alto como el de programas similares y se ejecuta lentamente. Algunos de estos problemas se pueden resolver internamente. una semana o un mes, y algunas se pueden solucionar en una semana o un mes. La mayoría de ellas son enfermedades persistentes que no se pueden curar. ¡Me han torturado hasta la muerte por este tipo de problema!
Por lo tanto, si desea aprender bien a programar, debe intentar resolver los problemas usted mismo. Especialmente como los programas ASP, no hay muchos problemas con la lógica. Los problemas que ocurren son básicamente informes de error y ubicaciones de error. No debería ser necesario analizarlos usted mismo. Creo que algunas personas están dispuestas a pasar tres días en el foro esperando que otros les cuenten sus problemas. ¿Por qué no lo resuelven ellos mismos? Si encuentra un problema usted mismo, obtendrá experiencia. ¡Esta es la riqueza de los programadores!
***Una pequeña experiencia de programador:
No crea que es programador sólo porque puede escribir unas pocas líneas de código o haber realizado algunos programas pequeños. Después de trabajar en una empresa de software durante algunos años, comprenderá lo que significa ser programador. Escribir código no es más que verificación y optimización de errores de código, escribir documentación de software (no un simple manual de usuario, sino una aplicación de proyecto, instrucciones de diseño preliminares del proyecto, instrucciones de diseño detalladas del proyecto, instrucciones de diseño de bases de datos, instrucciones de prueba del proyecto, manuales de usuario, instrucciones de usuario). manual de mantenimiento, etc.), hechos El hecho de que sepas programar no significa que puedas desarrollar software. De hecho, no soy lo suficientemente bueno en algunos aspectos, como escribir documentación de software. Jaja, ¡es aterrador pensar en eso! ¡Escribir documentación de software es mucho más doloroso que escribir un programa! Soy programador de Delphi desde hace tres años, aunque completé un buen proyecto de software cuando dejé la empresa. Pero todavía siento que soy insuficiente, así que ahora sigo sumando habilidades en otros aspectos. ¡La competencia en esta sociedad ya es muy feroz! ¡Cuanto menos trabajas, más trabajas para acercarte al desempleo!
Con respecto a la primera pregunta, te recomiendo encarecidamente que uses Dim para definir variables antes de usarlas. No es muy difícil escribir una línea más de código. Luego use <%Option Explicit%> en el encabezado del archivo ASP. De esta manera, si accidentalmente escribe el nombre de la variable incorrectamente, se devolverá un error de que la variable no está definida y se podrá encontrar fácilmente la ubicación del error. De lo contrario, la variable es un valor nulo.
Además, hablemos de la segunda pregunta junto con Option Explicit. A veces necesitamos incluir varios archivos (como definición de encabezado, navegación superior y otros códigos), y la opción explícita solo se puede usar en una aplicación ASP (tenga en cuenta que aquí se refiere a la aplicación, específicamente se refiere a una aplicación, no a una página, y no significa una página) una vez. Por lo tanto, es mejor no colocar la opción explícita dentro del archivo de inclusión para evitar la confusión causada por ser llamada varias veces en varias páginas.
Hablemos de una pequeña pregunta sobre incluir. Generalmente, si el archivo a incluir está en el directorio actual, podemos usar directamente
<!--#include file="abc.asp"-->
para incluirlo. Sin embargo, muchas veces tenemos N archivos que es necesario incluir. Por lo tanto, para facilitar la gestión, los ponemos en un directorio INC o include. De esta forma, en ocasiones el código de inclusión se escribe como:
<!--#include file="..incabc.asp" -->
Esto es lo que quiero discutir. Tenga en cuenta que el uso de .. puede acceder al directorio superior, lo que conlleva un riesgo de seguridad: los usuarios pueden hacer referencia ilegal a archivos fuera del sitio. Por este motivo, la herramienta IIS Lockdown publicada por Microsoft bloquea este método de referencia y Microsoft bloquea este método de forma predeterminada en IIS6.0 de Windows Server 2003. Para los archivos incluidos que no se encuentran en este directorio, se recomienda utilizar este método de referencia seguro:
<!--#include virtual="/inc/abc.asp"-->
Bienvenido a más exploraciones y debates útiles