1. การละเว้นการสลัวนั้นสะดวก แต่ยังเป็นอันตรายที่ซ่อนอยู่ด้วย!
การใช้ตัวแปรแล้วใช้มันเป็นแนวทางมาตรฐาน:
สลัว
ก = "1"
ที่จริงแล้ว คุณสามารถทำได้โดยไม่ต้องเขียนสลัว:
ก = "1"
ระบบไม่คิดว่าจะมีข้อผิดพลาด มันจะกำหนดโดยอัตโนมัติว่า a เป็นตัวแปรที่มีอยู่หรือไม่ หากไม่มี ระบบจะนำไปใช้โดยอัตโนมัติ ดูเหมือนว่าระบบจะฉลาด ฉลาด และเกรงใจ แต่ก็มีอันตรายซ่อนอยู่! ระบบรู้หรือไม่ว่าฉันหมายถึงอะไร? ระบบมีแนวโน้มที่จะฉลาดเกินไปและไม่เป็นประโยชน์! คำถามที่ 1: หากฉันเคยสมัครตัวแปรมาก่อน เช่น ผู้ดูแลระบบ และฉันต้องการกำหนดค่าให้กับตัวแปรนี้ในภายหลัง ฉันโชคไม่ดีที่เขียนตัวอักษรผิดหรือพลาด จดหมายเช่นผู้ดูแลระบบ = "ฉัน" ในที่สุดระบบก็รอโอกาสที่จะ "ช่วยเหลือ" ฉันและ "อาสา" ประกาศตัวแปรให้ฉัน มันยากที่จะแสดงว่ามัน "มีน้ำใจ" แค่ไหน! ใช่ โปรแกรมอาจสามารถทำงานได้ แต่ตรรกะเกิดข้อผิดพลาด เนื่องจากระบบไม่รายงานข้อผิดพลาด (หรือรายงานข้อผิดพลาดอื่นที่ทำให้คุณเข้าใจผิด) คุณจึงไม่สามารถระบุปัญหาได้อย่างรวดเร็ว หากโปรแกรมมีขนาดใหญ่ คุณจะทำได้ ใช้เวลามากมาย คุณรู้สึกอย่างไรหลังจากใช้เวลาค้นหาสาเหตุที่แท้จริง? คุณคงอยากจะดุระบบว่า "มีกำลังใจในตัวเอง" ถ้าระบบรายงานว่าไม่มีชื่อตัวแปรของผู้ดูแลระบบ ฉันจะรู้ทันทีว่าฉันสะกดผิดและแก้ไขปัญหาได้อย่างรวดเร็วโดยไม่ต้อง "ตามใจ" ระบบ "อัตโนมัติ" หลงใหล! อันตรายที่ซ่อนอยู่อีกประการหนึ่งที่เกิดจากการละเว้นการสลัว จะมีการพูดคุยกันในภายหลัง!
2. ตัวแปรที่ประกาศภายในฟังก์ชันจะไม่รบกวนตัวแปรภายนอก!
ตัวอย่างเช่น:
< %@LANGUAGE="VBSCRIPT " CODEPAGE="936"%>
-
สลัว
ก = "1"
ฟังก์ชัน getstr()
สลัว
ก = "2"
สิ้นสุด
การตอบสนองของฟังก์ชัน เขียน & "<br>"
รับstr()
การตอบกลับ เขียน & "<br>"
%>
ผลปรากฏว่าตัวแปรที่ประกาศไว้ภายในฟังก์ชันจะไม่รบกวนโลกภายนอก จริงๆ แล้วทุกคนที่เรียนภาษาอื่นควรรู้เรื่องนี้! แต่ต้องระบุก่อนว่าถ้า dim a ภายในฟังก์ชันถูกลบออก จะถือว่า a เป็น a ภายนอก และผลลัพธ์จะเปลี่ยนไป! ขอบเขตของตัวแปรที่ใช้ในไฟล์คือไฟล์นี้
3. รวมที่ทำให้คนทั้งรักและเกลียด!
รวมสามารถทำให้โครงสร้างของโปรแกรม ASP ชัดเจนขึ้น และบางฟังก์ชันที่ใช้กันทั่วไปสามารถแชร์โดยไฟล์อื่นได้! แม้จะนำมาซึ่งประโยชน์ แต่ก็ต้องใส่ใจกับข้อเสียด้วย!
ตอนนี้กลับมาที่การละเว้นการสลัวที่กล่าวถึงในประเด็นแรก สิ่งที่ฉันกล่าวถึงก่อนหน้านี้คืองานของฉันถูกเปลี่ยนเป็นตัวแปรที่ระบบประกาศไว้อย่าง "กรุณา" สิ่งที่ฉันกำลังพูดถึงตอนนี้ตรงกันข้ามเลย ฉันต้องการประกาศตัวแปร แต่ระบบจะกำหนดค่าให้กับมันเนื่องจากเป็นไปได้ที่จะประกาศตัวแปรแม้ว่าจะละเว้น dim ก็ตาม สำหรับโปรแกรมเมอร์ที่ชอบบันทึกและทำให้ง่ายขึ้น มักจะอดใจไม่ไหว (บางทีก็ชอบสมัครแบบนี้บ้าง อิอิ) แต่รับประกันได้ไหมว่าชื่อตัวแปรที่สมัครไม่อยู่ในโปรแกรมก่อนหน้านั้น? ถ้ามีชื่อตัวแปรนี้อยู่ข้างหน้า แสดงว่าสมัครเข้าทำงานแล้วใช่หรือไม่? ข้อผิดพลาดนี้อาจไม่ค่อยเกิดขึ้นในไฟล์เดียวกัน แต่อย่าลืมรวมไว้ด้วย หากไฟล์ที่รวมไว้มีตัวแปรที่คุณสมัคร แสดงว่าไฟล์นั้นสามารถทำงานได้แล้ว ปัญหาเชิงตรรกะ หากคุณไม่ขี้เกียจและใช้ dim เพื่อใช้ เมื่อมีการรายงานข้อผิดพลาด คุณจะโชคดีที่รู้ว่าชื่อตัวแปรนี้มีอยู่แล้ว! จะได้รับการแก้ไขเร็วๆ นี้!
ตอนนี้เรามาพูดถึงสถานการณ์ที่ซับซ้อนมากขึ้น หากคุณรวมสองไฟล์ จะมีชื่อตัวแปรเดียวกันในทั้งสองไฟล์ หากคุณใช้ dim เพื่อใช้ทั้งสองไฟล์ โอเค มันจะรายงานข้อผิดพลาดโดยบอกว่ามีชื่อตัวแปรอยู่แล้ว คุณจะรู้ปัญหาในไม่ช้า ตอนนี้คุณสามารถเข้าใจแล้วว่าทำไมฉันถึงพูดถึงขอบเขตจุดที่สอง เนื่องจากขอบเขต ตัวแปรที่มีชื่อเดียวกันในไฟล์ต่างกันโดยทั่วไปจะไม่ "ต่อสู้" อย่างไรก็ตาม หากมีการรวมไว้ในไฟล์อื่นในเวลาเดียวกัน ปัญหาก็จะเป็นปัญหา ดังนั้นหากตั้งใจที่จะรวมไฟล์ asp ที่คุณเขียนไว้ด้วย โปรดป้องกันไม่ให้สถานการณ์ที่มีชื่อเดียวกันนี้เกิดขึ้น กลับไปที่การสนทนาแบบเดิม คงจะดีถ้าทั้งสองมีตัวแปรที่มีชื่อเดียวกันเป็นค่าสลัวเมื่อใช้กับไฟล์รวมทั้งสองไฟล์ แต่ปัญหาจะเกิดขึ้นหากไฟล์ที่รวมไว้ในภายหลังถูกนำไปใช้โดยละเว้นแอปพลิเคชัน dim ที่ละเว้นในภายหลัง กลายเป็นงานมอบหมาย สิ่งที่แย่มากคือ มันมีไฟล์รวมอยู่สองไฟล์ซึ่งถูกซ่อนไว้มาก ทำให้ค้นหาปัญหาได้ยากขึ้น!
โดยสรุป คุณสามารถเขียนตัวอย่างง่ายๆ เพื่อทำความเข้าใจปัญหาได้ สุดท้ายนี้ ฉันขอแนะนำ:
1. โปรดใช้ dim เพื่อใช้กับตัวแปรก่อนใช้งาน! โดยเฉพาะโปรแกรมที่ซับซ้อนซึ่งพัฒนาโดยคนหลายคน!
2. เมื่อกำหนดค่าให้กับตัวแปรโปรดใส่ใจกับการสะกดของตัวแปรด้วย!
3. ทำความเข้าใจไฟล์รวมอย่างรอบคอบ
***ทีนี้มาพูดถึงการตรวจสอบข้อผิดพลาดกันดีกว่า
ที่จริงแล้ว การค้นหาปัญหาสำคัญกว่าการเขียนโค้ด! จากประสบการณ์ส่วนตัวของผม ปัญหาแบ่งออกเป็น 3 ประเภท คือ
1. ประเภทการรายงานข้อผิดพลาด ปัญหาที่ระบบคอมไพล์พบระหว่างกระบวนการคอมไพล์ของระบบจะทำให้เกิดข้อความแสดงข้อผิดพลาด นี่คือปัญหายอดนิยมของโปรแกรมเมอร์ 555 ไม่ใช่เรื่องผิดปกติ แต่ปัญหาประเภทนี้คือ เช็คง่ายที่สุด!
2. ประเภทลอจิก เป็นปัญหาที่ค่อนข้างน่ารำคาญ โปรแกรมได้รับการคอมไพล์สำเร็จและสามารถรันได้ แต่ผลลัพธ์ที่แสดงไม่ใช่ผลลัพธ์ที่คาดหวังในตรรกะของคุณ โอ้พระเจ้า! ฉันควรทำอย่างไรไม่มีข้อความแจ้งฉันสามารถวิเคราะห์ผลลัพธ์ข้อผิดพลาดตามประสบการณ์และความรู้สึกเท่านั้นจากนั้นตรวจสอบซอร์สโค้ดหากทุกอย่างเป็นไปด้วยดีก็จะแก้ไขได้ภายในไม่กี่นาที ผลลัพธ์หลังจากวันที่ยากลำบาก!
3. หมวดหมู่ประสิทธิภาพ ปัญหาร้ายแรง โปรแกรมได้รับการคอมไพล์สำเร็จ ทำงานตามปกติ และแสดงผลได้ตามปกติ! อย่างไรก็ตาม บางครั้งข้อผิดพลาดเกิดขึ้นกับคุณเป็นระยะๆ และคุณไม่รู้ว่าในสถานการณ์ใดที่ข้อผิดพลาดเกิดขึ้น หรือประสิทธิภาพของโปรแกรมไม่สูงเท่ากับโปรแกรมที่คล้ายกันและทำงานช้า ปัญหาเหล่านี้บางส่วนสามารถแก้ไขได้ภายใน หนึ่งสัปดาห์หรือหนึ่งเดือนและบางส่วนสามารถแก้ไขได้ภายในหนึ่งสัปดาห์หรือหนึ่งเดือนส่วนใหญ่เป็นโรคที่รักษาไม่หาย ฉันถูกทรมานจนตายจากปัญหาแบบนี้!
ดังนั้นหากคุณต้องการเรียนรู้การเขียนโปรแกรมให้ดีคุณต้องพยายามแก้ไขปัญหาด้วยตัวเอง โดยเฉพาะเช่นโปรแกรม ASP ปัญหาที่เกิดขึ้นโดยทั่วไปมีข้อความแสดงข้อผิดพลาดและตำแหน่งข้อผิดพลาด ไม่น่าจะต้องวิเคราะห์ด้วยตัวเอง ฉันคิดว่าบางคนยินดีที่จะใช้เวลาสามวันในฟอรั่มเพื่อรอให้คนอื่นบอกปัญหาของพวกเขาเอง หากคุณพบปัญหาด้วยตนเอง คุณจะได้รับประสบการณ์ นี่คือความมั่งคั่งของโปรแกรมเมอร์!
***ประสบการณ์โปรแกรมเมอร์เล็กน้อย:
อย่าคิดว่าคุณเป็นโปรแกรมเมอร์เพียงเพราะคุณสามารถเขียนโค้ดได้ไม่กี่บรรทัดหรือเคยทำโปรแกรมเล็กๆ น้อยๆ บ้าง หลังจากที่คุณทำงานในบริษัทซอฟต์แวร์มาได้สองสามปี คุณจะเข้าใจว่าการเป็นโปรแกรมเมอร์หมายความว่าอย่างไร การเขียนโค้ดไม่ใช่อะไรนอกจากการตรวจสอบข้อผิดพลาดของโค้ดและการปรับให้เหมาะสม รหัส เขียนเอกสารซอฟต์แวร์ (ไม่ใช่คู่มือผู้ใช้ธรรมดา แต่เป็นแอปพลิเคชันโครงการ คำแนะนำการออกแบบเบื้องต้นของโครงการ คำแนะนำการออกแบบโดยละเอียดของโครงการ คำแนะนำการออกแบบฐานข้อมูล คำแนะนำการทดสอบโครงการ คู่มือผู้ใช้ ผู้ใช้ คู่มือการบำรุงรักษา ฯลฯ) ข้อเท็จจริง เพียงเพราะคุณสามารถเขียนโปรแกรมได้ ไม่ได้หมายความว่าคุณสามารถพัฒนาซอฟต์แวร์ได้ จริงๆ แล้วผมยังดีไม่พอในบางด้าน เช่น การเขียนเอกสารซอฟต์แวร์ ฮ่าๆ คิดแล้วน่ากลัวกว่าการเขียนเอกสารซอฟต์แวร์ซะอีก ฉันเป็นโปรแกรมเมอร์ของ Delphi มาสามปีแล้ว แม้ว่าฉันจะทำโปรเจ็กต์ซอฟต์แวร์ดีๆ สำเร็จเมื่อออกจากบริษัทก็ตาม แต่ฉันยังรู้สึกว่าตัวเองยังไม่เพียงพอ ดังนั้น ตอนนี้ฉันยังคงเพิ่มทักษะในด้านอื่น ๆ ต่อไป การแข่งขันในสังคมนี้ดุเดือดมากแล้ว
สำหรับคำถามแรก ฉันขอแนะนำอย่างยิ่งให้คุณใช้ Dim เพื่อกำหนดตัวแปรก่อนใช้งาน การเขียนโค้ดเพิ่มอีกบรรทัดหนึ่งไม่ใช่เรื่องยาก จากนั้นใช้ <%Option Explicit%> ในส่วนหัวของไฟล์ ASP ด้วยวิธีนี้ หากคุณเขียนชื่อตัวแปรไม่ถูกต้องโดยไม่ตั้งใจ ข้อผิดพลาดที่ไม่ได้กำหนดตัวแปรจะถูกส่งกลับ และตำแหน่งข้อผิดพลาดจะสามารถค้นหาได้ง่าย มิฉะนั้นตัวแปรจะเป็นค่า Null
นอกจากนี้ เรามาพูดถึงคำถามที่สองร่วมกับ Option Explicit กัน บางครั้งเราจำเป็นต้องรวมหลายไฟล์ (เช่น คำนิยามส่วนหัว การนำทางด้านบน และโค้ดอื่นๆ) และตัวเลือก Explicit สามารถใช้ได้เฉพาะในแอปพลิเคชัน ASP เท่านั้น (โปรดทราบว่ามันอ้างถึงแอปพลิเคชันที่นี่ โดยเฉพาะอ้างถึงแอปพลิเคชัน ไม่ใช่หน้า และ ไม่ได้หมายถึงหน้า) ครั้งเดียว ดังนั้น ไม่ควรวาง Option Explicit ไว้ในไฟล์รวม เพื่อหลีกเลี่ยงความสับสนที่เกิดจากการถูกเรียกหลายครั้งในหลายหน้า
เรามาพูดถึงคำถามเล็กๆ น้อยๆ เกี่ยวกับการรวมกัน โดยทั่วไปหากไฟล์ที่จะรวมอยู่ในไดเร็กทอรีปัจจุบันเราสามารถใช้งานได้โดยตรง
<!--#include file="abc.asp"-->
เพื่อรวมไว้ อย่างไรก็ตาม หลายครั้งที่เรามีไฟล์ N ไฟล์ที่ต้องรวมไว้ด้วย ดังนั้น เพื่ออำนวยความสะดวกในการจัดการ เราจึงรวมไว้ใน INC หรือรวมไดเร็กทอรีด้วย ด้วยวิธีนี้ บางครั้งโค้ด include จะถูกเขียนเป็น:
<!--#include file="..incabc.asp" -->
นี่คือสิ่งที่ฉันต้องการพูดคุย โปรดทราบว่าการใช้ .. สามารถเข้าถึงไดเร็กทอรีด้านบนซึ่งนำมาซึ่งความเสี่ยงด้านความปลอดภัย: ผู้ใช้อาจอ้างอิงไฟล์นอกไซต์อย่างผิดกฎหมาย ด้วยเหตุนี้ เครื่องมือ IIS Lockdown ที่ Microsoft เปิดตัวจึงบล็อกวิธีการอ้างอิงนี้ และ Microsoft บล็อกวิธีนี้ตามค่าเริ่มต้นใน IIS6.0 ของ Windows Server 2003 สำหรับไฟล์ที่รวมไว้ซึ่งไม่อยู่ในไดเร็กทอรีนี้ ขอแนะนำให้ใช้วิธีอ้างอิงที่ปลอดภัยนี้:
<!--#include virtual="/inc/abc.asp"-->
ยินดีต้อนรับการสำรวจและการสนทนาที่เป็นประโยชน์มากขึ้น