ความคิดเห็นเกี่ยวกับซอร์สโค้ดเคล็ดลับการกำหนดสไตล์และแนวทางปฏิบัติที่ดีที่สุด
นักพัฒนาที่ใช้เวลาในโครงการขนาดใหญ่เข้าใจถึงความสำคัญของการแสดงความคิดเห็นเกี่ยวกับโค้ด เมื่อคุณสร้างคุณสมบัติมากมายในแอพพลิเคชั่นเดียวกันสิ่งต่าง ๆ มักจะมีความซับซ้อน มีบิตข้อมูลจำนวนมากรวมถึงฟังก์ชั่นการอ้างอิงตัวแปรค่าส่งคืนพารามิเตอร์ ... คุณคาดหวังที่จะรักษาอย่างไร?
ไม่น่าแปลกใจเลยที่การแสดงความคิดเห็นรหัสของคุณเป็นสิ่งจำเป็นทั้งโครงการเดี่ยวและโครงการ แต่นักพัฒนาหลายคนไม่ทราบว่าจะทำอย่างไรกับกระบวนการนี้ ฉันได้แสดงกลวิธีส่วนตัวบางอย่างของฉัน การสร้างความคิดเห็นโค้ดที่จัดรูปแบบเรียบร้อย. เทมเพลตมาตรฐานและข้อคิดเห็นจะแตกต่างกันระหว่างนักพัฒนา แต่ท้ายที่สุดคุณควรพยายามทำ ทำความสะอาดและแสดงความคิดเห็น เพื่ออธิบายเพิ่มเติมเกี่ยวกับพื้นที่ที่สับสนในรหัสของคุณ.
เราควรเริ่มพูดคุยเกี่ยวกับความแตกต่างบางประการในการจัดรูปแบบความคิดเห็น สิ่งนี้จะช่วยให้คุณมีความคิดที่ดีขึ้นว่ารายละเอียดของคุณจะเป็นอย่างไรกับรหัสโครงการ หลังจากนั้นฉันจะเสนอเคล็ดลับและตัวอย่างเฉพาะซึ่งคุณสามารถเริ่มใช้งานได้ทันที!
สไตล์ความคิดเห็น: ภาพรวม
ควรสังเกตว่าแนวคิดเหล่านี้นำเสนอเป็นเพียง แนวทาง ที่มีต่อความคิดเห็นที่สะอาด ภาษาการเขียนโปรแกรมส่วนบุคคลไม่ได้กำหนดแนวทางหรือข้อกำหนดสำหรับวิธีการตั้งค่าเอกสารของคุณ.
ดังที่กล่าวไปแล้วผู้พัฒนาในยุคปัจจุบันได้รวมตัวกันเพื่อจัดรูปแบบระบบการแสดงความคิดเห็นโค้ดของตนเอง ฉันจะเสนอรูปแบบหลัก ๆ สองสามอย่างและดูรายละเอียดเกี่ยวกับวัตถุประสงค์ของพวกเขา.
การแสดงความคิดเห็นแบบอินไลน์
ทุกข้อเสนอภาษาการเขียนโปรแกรมเดียวจริง ความคิดเห็นแบบอินไลน์. สิ่งเหล่านี้ถูก จำกัด ไว้ที่เนื้อหาบรรทัดเดียวและแสดงความคิดเห็นข้อความหลังจากจุดที่แน่นอน ตัวอย่างเช่นใน C / C ++ คุณเริ่มแสดงความคิดเห็นแบบอินไลน์ดังนี้:
// เริ่มตัวแปรรายการ var myvar = 1; ...
นี่คือที่สมบูรณ์แบบสำหรับการตีรหัสเข้าไปในไม่กี่วินาที อธิบายฟังก์ชั่นที่อาจสับสน. หากคุณกำลังทำงานกับพารามิเตอร์หรือการเรียกใช้ฟังก์ชันจำนวนมากคุณอาจแสดงความคิดเห็นแบบอินไลน์ใกล้เคียง แต่ประโยชน์ที่ได้รับมากที่สุดคือ คำอธิบายง่ายๆสำหรับฟังก์ชั่นขนาดเล็ก.
if (callAjax ($ params)) // รัน callAjax สำเร็จด้วยพารามิเตอร์ผู้ใช้… code
โปรดสังเกตว่ารหัสทั้งหมดจะต้องอยู่ในบรรทัดใหม่หลังจากวงเล็บเปิด มิฉะนั้นจะถูกจับในบรรทัดความคิดเห็นเดียวกันทั้งหมด! หลีกเลี่ยงการลงน้ำ เนื่องจากโดยทั่วไปคุณไม่จำเป็นต้องเห็นความคิดเห็นบรรทัดเดียวตลอดจนหน้าเว็บของคุณ แต่โดยเฉพาะอย่างยิ่งสำหรับจุดแยกที่สับสนในรหัสของคุณสิ่งเหล่านี้ง่ายกว่ามากที่จะดรอปในนาทีสุดท้าย.
บล็อกพรรณนา
เมื่อคุณจำเป็นต้องมีคำอธิบายขนาดใหญ่โดยทั่วไปซับเดี่ยวจะไม่ทำเคล็ดลับ มีเทมเพลตข้อคิดเห็นที่มีการจัดรูปแบบไว้ล่วงหน้าซึ่งใช้ในทุก ๆ ส่วนของการเขียนโปรแกรม. บล็อกอธิบาย จะเห็นสะดุดตาที่สุดรอบฟังก์ชั่นและไฟล์ไลบรารี เมื่อใดก็ตามที่คุณตั้งค่าฟังก์ชั่นใหม่มันเป็นการปฏิบัติที่ดี เพิ่มบล็อกที่เป็นคำอธิบายด้านบนการประกาศ.
/ ** * @desc เปิดหน้าต่าง modal เพื่อแสดงข้อความ * @param string $ msg - ข้อความที่จะแสดง * @return bool - สำเร็จหรือล้มเหลว * / ฟังก์ชั่น modalPopup ($ msg) …
ด้านบนเป็นตัวอย่างง่ายๆของการแสดงความคิดเห็นฟังก์ชั่นอธิบาย ฉันได้เขียนฟังก์ชั่นน่าจะเป็นใน JavaScript ที่เรียกว่า modalPopup ซึ่งใช้พารามิเตอร์เดียว ในความคิดเห็นด้านบนฉันใช้ไวยากรณ์คล้ายกับ phpDocumentor โดยที่แต่ละบรรทัดนำหน้าด้วย แอท สัญลักษณ์ตามด้วยปุ่มที่เลือก สิ่งเหล่านี้จะไม่ส่งผลกระทบต่อโค้ดของคุณ แต่อย่างใดดังนั้นคุณจึงสามารถเขียนได้ @description
แทน @desc
ไม่มีการเปลี่ยนแปลงใด ๆ.
ปุ่มเล็ก ๆ เหล่านี้เรียกว่าจริง ๆ แล้ว แท็กความคิดเห็น ซึ่งเป็นเอกสารอย่างมากในเว็บไซต์ อย่าลังเลที่จะสร้างของคุณเองและใช้สิ่งเหล่านี้ตามที่คุณต้องการตลอดทั้งรหัสของคุณ ฉันพบว่าพวกเขาช่วยให้ทุกอย่างไหลลื่น ฉันสามารถตรวจสอบข้อมูลสำคัญได้อย่างรวดเร็ว. คุณควรสังเกตว่าฉันได้ใช้ / * * /
รูปแบบการแสดงความคิดเห็นสไตล์บล็อก สิ่งนี้จะทำให้ทุกอย่าง ทำความสะอาดมาก กว่าการเพิ่มเครื่องหมายสแลชสองครั้งที่แต่ละบรรทัด.
ความคิดเห็นกลุ่ม / คลาส
นอกเหนือจากการแสดงความคิดเห็นฟังก์ชั่นและลูปพื้นที่บล็อกจะไม่ถูกใช้งานบ่อยเท่าที่ควร ในที่ที่คุณต้องการความแข็งแกร่ง บล็อกความคิดเห็น อยู่ที่หัวเอกสารแบ็กเอนด์หรือไฟล์ไลบรารีของคุณ เป็นเรื่องง่ายที่จะออกไปอย่างเต็มที่และเขียนเอกสารที่เป็นของแข็งสำหรับไฟล์ทุกไฟล์ในเว็บไซต์ของคุณ - เราสามารถเห็นแนวปฏิบัตินี้ใน CMS จำนวนมากเช่น WordPress.
พื้นที่ส่วนบนสุดของหน้าของคุณควรเก็บความคิดเห็นเกี่ยวกับตัวไฟล์เอง ด้วยวิธีนี้คุณสามารถ ตรวจสอบอย่างรวดเร็วว่าคุณกำลังแก้ไขอยู่ที่ไหน เมื่อทำงานกับหลาย ๆ หน้าในเวลาเดียวกัน นอกจากนี้คุณสามารถใช้พื้นที่นี้เป็น ฐานข้อมูลสำหรับฟังก์ชั่นที่สำคัญที่สุดที่คุณต้องการ ออกจากชั้นเรียน.
/ ** * @desc คลาสนี้จะมีฟังก์ชั่นสำหรับการโต้ตอบกับผู้ใช้ * ตัวอย่าง ได้แก่ user_pass (), user_username (), user_age (), user_regdate () * @author Jake Rocheleau [email protected] * @required settings.php * / คลาสนามธรรม myWebClass
คุณจะเห็นว่าฉันใช้คลาสตัวอย่างขนาดเล็กสำหรับของปลอม myWebClass
รหัส. ฉันได้เพิ่มข้อมูลเมตาแล้ว ด้วยชื่อและที่อยู่อีเมลของฉันสำหรับการติดต่อ. เมื่อนักพัฒนากำลังเขียนโค้ดโอเพนซอร์ซนี่เป็นวิธีปฏิบัติที่ดีโดยทั่วไปดังนั้นผู้อื่นอาจติดต่อคุณเพื่อขอความช่วยเหลือ นี่เป็นวิธีที่มั่นคงเมื่อทำงานในทีมพัฒนาขนาดใหญ่.
แท็ก @required
ไม่ใช่สิ่งที่ฉันเคยเห็นใช้ในที่อื่น ฉันติดตามรูปแบบในโปรเจ็กต์ของฉันไม่กี่หน้าเฉพาะในหน้าเว็บที่ฉันกำหนดวิธีการมากมาย เมื่อใดก็ตามที่คุณรวมหน้าเป็นไฟล์พวกเขาจะต้องมาก่อนที่คุณจะส่งออกรหัสใด ๆ ดังนั้นการเพิ่มรายละเอียดเหล่านี้ลงในบล็อคความคิดเห็นระดับหลักจึงเป็นวิธีที่ดี จำไฟล์ที่จำเป็น.
การแสดงความคิดเห็นรหัส Front-end
ตอนนี้เราได้ครอบคลุมแม่แบบความคิดเห็นที่สำคัญ 3 แบบลองมาดูตัวอย่างอื่น ๆ มีผู้พัฒนาส่วนหน้าจำนวนมากที่ย้ายจาก HTML แบบคงที่ไปเป็น jQuery และโค้ด CSS ความคิดเห็น HTML นั้นไม่ได้มีวัตถุประสงค์เมื่อเทียบกับแอปพลิเคชั่นการเขียนโปรแกรม แต่เมื่อคุณกำลังเขียนไลบรารีสไตล์และสคริปต์ของหน้าเว็บอาจยุ่งเหยิงไปตามกาลเวลา.
JavaScript ใช้วิธีดั้งเดิมในการแสดงความคิดเห็นคล้ายกับ Java, PHP และ C / C++. CSS ใช้ความคิดเห็นสไตล์บล็อกเท่านั้นที่กำหนดโดยเครื่องหมายสแลชและดอกจัน. คุณควรจำไว้ว่าความคิดเห็นจะถูกเปิดเผยต่อผู้เยี่ยมชมอย่างเปิดเผยเนื่องจาก CSS หรือ JS ไม่ได้แยกวิเคราะห์ฝั่งเซิร์ฟเวอร์ แต่วิธีใดวิธีหนึ่งเหล่านี้ใช้ได้ดีในการทิ้งเกร็ดความรู้ที่เป็นข้อมูลไว้ในโค้ดของคุณเพื่อย้อนกลับไป.
การแยกไฟล์ CSS โดยเฉพาะอาจเป็นงานที่น่าเบื่อ เราทุกคนต่างคุ้นเคยกับการแสดงความคิดเห็นแบบอินไลน์เพื่ออธิบายการแก้ไขสำหรับ Internet Explorer หรือ Safari แต่ฉันเชื่อว่า CSS comment สามารถใช้ได้ในระดับ jQuery และ PHP ใช้พวกเขา มาเจาะลึกการสร้างกลุ่มสไตล์ก่อนที่จะสัมผัสกับเคล็ดลับโดยละเอียดเกี่ยวกับการใส่รหัสความคิดเห็น.
กลุ่มสไตล์ CSS
สำหรับผู้ที่ได้รับการออกแบบ CSS มานานหลายปีมันเกือบจะเป็นลักษณะที่สอง คุณค่อย ๆ จดจำคุณสมบัติทั้งหมดไวยากรณ์และสร้างระบบของคุณเองสำหรับสไตล์ชีต จากการทำงานของตัวเองฉันได้สร้างสิ่งที่ฉันเรียก หมวดหมู่ เพื่อจับคู่บล็อก CSS ที่คล้ายกันไว้ในที่เดียว.
เมื่อกลับไปแก้ไข CSS ฉันสามารถค้นหาสิ่งที่ฉันต้องการได้ในไม่กี่วินาที วิธีที่คุณเลือกสไตล์กลุ่มนั้นขึ้นอยู่กับคุณทั้งหมดและนั่นคือความงามของระบบนี้ ฉันมีมาตรฐานที่กำหนดไว้ล่วงหน้าเล็กน้อยซึ่งได้อธิบายไว้ด้านล่าง:
- @resets - กำจัดค่าเริ่มต้นของเบราว์เซอร์ระยะห่างช่องว่างภายในแบบอักษรแบบอักษรสี ฯลฯ.
- @fonts - ย่อหน้า, ส่วนหัว, blockquotes, ลิงก์, รหัส
- @navigation - ลิงก์หลักการนำทางเว็บไซต์หลัก
- @layout - wrapper, container, sidebars
- @header & @footer - สิ่งเหล่านี้อาจแตกต่างกันไปตามการออกแบบของคุณ สไตล์ที่เป็นไปได้ ได้แก่ ลิงก์และรายการที่ไม่เรียงลำดับคอลัมน์ส่วนท้ายส่วนหัว sub-navs
เมื่อจัดกลุ่มสไตล์ชีตฉันพบ ระบบติดแท็ก สามารถช่วยได้มาก อย่างไรก็ตามแตกต่างจาก PHP หรือ JavaScript ฉันใช้เพียงครั้งเดียว @กลุ่ม แท็กตามด้วยหมวดหมู่หรือคำหลัก ฉันได้รวม 2 ตัวอย่างไว้ด้านล่างเพื่อให้คุณรู้สึกถึงความหมายที่แท้จริง.
/ ** @group footer * / #footer styles …
/ ** @ ส่วนท้ายของกลุ่มแบบอักษรขนาดเล็กคอลัมน์ลิงก์ภายนอก ** /
หรือคุณสามารถเพิ่มรายละเอียดเล็กน้อยในแต่ละบล็อกความคิดเห็น ฉันเลือกที่จะ ทำสิ่งที่ง่ายและตรงไปตรงมา ดังนั้นสไตล์ชีทจึงอ่านง่าย การแสดงความคิดเห็นเป็นข้อมูลเกี่ยวกับเอกสารดังนั้นตราบใดที่คุณเข้าใจการเขียนเป็นเรื่องดี!
4 เคล็ดลับเพื่อความคิดเห็นที่ดีขึ้น
เราใช้เวลาครึ่งแรกของบทความนี้เพื่อดูรูปแบบต่างๆสำหรับการแสดงความคิดเห็นรหัส ตอนนี้เรามาพูดถึงเคล็ดลับโดยรวมในการทำให้โค้ดของคุณสะอาดจัดระเบียบและเข้าใจง่าย.
1. ให้ทุกอย่างอ่านได้
บางครั้งในฐานะนักพัฒนาเราลืมมันไป เรากำลังเขียนความคิดเห็นเพื่อให้มนุษย์อ่าน. ภาษาการเขียนโปรแกรมทั้งหมดที่เราเข้าใจถูกสร้างขึ้นสำหรับเครื่องดังนั้นมันจึงน่าเบื่อที่จะแปลงเป็นข้อความธรรมดา เป็นสิ่งสำคัญที่จะต้องทราบว่าเราไม่ได้อยู่ที่นี่เพื่อเขียนรายงานการวิจัยระดับวิทยาลัย แต่ เพิ่งออกจากเคล็ดลับ!
ฟังก์ชั่น getTheMail () // รหัสที่นี่จะสร้างอีเมล / * เรียกใช้รหัสถ้า sendMyMail ที่กำหนดเองของเรา () ฟังก์ชั่นการโทรกลับจริงพบ findMyMail () ใน /libs/mailer.class.php เราตรวจสอบว่าผู้ใช้เติมในทุกสาขา และส่งข้อความ! * / if (sendMyMail ()) return true; // รักษาความจริงและแสดงความสำเร็จบนหน้าจอ
แม้แต่คำเพียงไม่กี่คำ ดีกว่าไม่มีอะไร. เมื่อคุณกลับไปแก้ไขและทำงานในโครงการในอนาคตมักจะแปลกใจว่าคุณจะลืมไปมากแค่ไหน เนื่องจากคุณไม่ได้ดูตัวแปรและชื่อฟังก์ชั่นเดียวกันทุกวันคุณมักจะลืมรหัสส่วนใหญ่อย่างช้าๆ ดังนั้นคุณสามารถ อย่าแสดงความคิดเห็นมากเกินไป! แต่คุณสามารถแสดงความคิดเห็นที่ไม่ดีได้มากเกินไป.
เป็นกฎทั่วไปของหัวแม่มือ, ใช้เวลาในการหยุดชั่วคราวและไตร่ตรองก่อนเขียน. ถามตัวเอง สิ่งที่สับสนมากที่สุดเกี่ยวกับโปรแกรม และ คุณจะอธิบายให้ดีที่สุดได้อย่างไร “ตัวแทนเชิด” ภาษา? ยังพิจารณา ทำไมคุณถึงเขียนรหัสตรงตามที่คุณเป็น.
ข้อผิดพลาดที่สับสนมากที่สุดจะปรากฏขึ้นเมื่อคุณลืมวัตถุประสงค์ของฟังก์ชั่นที่สร้างขึ้นเอง (หรือบุคคลที่สาม). ทิ้งความคิดเห็นไว้ซึ่งนำกลับไปยังไฟล์อื่นไม่กี่ไฟล์ ถ้านี่จะช่วยให้คุณจำการทำงานได้ง่ายขึ้น.
2. บรรเทาบางพื้นที่!
ฉันไม่สามารถเครียดพอสำคัญแค่ไหน ช่องว่าง เป็นไปได้. สิ่งนี้จะไป จริงทวีคูณ สำหรับนักพัฒนา PHP และ Ruby ที่ทำงานบนเว็บไซต์ขนาดใหญ่ที่มีไฟล์นับร้อย คุณจะจ้องมองที่รหัสนี้ตลอดทั้งวัน! มันจะไม่ดีถ้าคุณสามารถผ่านไปยังพื้นที่สำคัญ?
$ dir1 = "/ home /"; // ตั้งค่าโฮมไดเร็คทอรี่หลัก $ myCurrentDir = getCurDirr (); // กำหนดไดเรกทอรีผู้ใช้ปัจจุบัน $ userVar = $ get_username (); // ชื่อผู้ใช้ปัจจุบันของผู้ใช้
ในตัวอย่างข้างต้นคุณจะสังเกตเห็นช่องว่างภายในเพิ่มเติมที่ฉันวางไว้ระหว่างความคิดเห็นและรหัสในแต่ละบรรทัด ในขณะที่คุณเลื่อนดูไฟล์รูปแบบการแสดงความคิดเห็นนี้จะ โดดเด่นอย่างชัดเจน. มัน ทำให้การค้นหาข้อผิดพลาดและการแก้ไขรหัสของคุณง่ายขึ้นหลายร้อยครั้ง เมื่อบล็อกตัวแปรเป็นเช่นนั้น สะอาด.
คุณสามารถทำงานที่คล้ายกันในรหัสที่อยู่ภายในฟังก์ชั่นที่คุณสับสนเกี่ยวกับวิธีการทำงาน แต่ในที่สุดวิธีการนี้จะทำให้โค้ดของคุณยุ่งเหยิงด้วยความคิดเห็นแบบอินไลน์และนั่นเป็นสิ่งที่ตรงกันข้ามอย่างแน่นอน! ฉันแนะนำในสถานการณ์นี้ การเพิ่มความคิดเห็นบล็อกบรรทัดขนาดใหญ่รอบ ๆ พื้นที่ของตรรกะ.
$ (เอกสาร). ready (ฟังก์ชั่น () $ ('. sub'). hide (); // ซ่อนการนำทางย่อยใน pageload / ** ตรวจสอบเหตุการณ์การคลิกที่จุดยึดใน. it div ป้องกันการเชื่อมโยง การกระทำเพื่อให้หน้าไม่เปลี่ยนแปลงเมื่อคลิกเข้าถึงองค์ประกอบหลักของ. it ตามด้วยรายการ. ย่อยถัดไปเพื่อสลับเปิด / ปิด ** / $ ('. itm a'). live ('คลิก', ฟังก์ชั่น (e ) e.preventDefault (); $ (this) .parent (). next ('. sub'). slideToggle ('เร็ว');););
นี่เป็นรหัส jQuery เล็ก ๆ ซึ่งกำหนดเป้าหมายการนำทางเลื่อนเมนูย่อย ความคิดเห็นแรกเป็นแบบอินไลน์เพื่ออธิบายว่าทำไมเราจึงซ่อนทั้งหมด .ย่อย
ชั้นเรียน เหนือตัวจัดการเหตุการณ์คลิกสดฉันได้ใช้ความคิดเห็นแบบบล็อกและ เยื้องการเขียนทั้งหมดไปยังจุดเดียวกัน. สิ่งนี้ทำให้สิ่งต่าง ๆ น่าสนใจมากกว่าการใช้ย่อหน้า - โดยเฉพาะอย่างยิ่งสำหรับคนอื่นที่อ่านความคิดเห็นของคุณ.
3. ความคิดเห็นในขณะที่การเข้ารหัส
นอกจากระยะห่างที่เหมาะสมแล้วนี่อาจเป็นหนึ่งในนิสัยที่ดีที่สุดในการเข้าสู่ ไม่มีใครอยากกลับไปใช้โปรแกรมหลังจากทำงานและบันทึกทุกชิ้น พวกเราส่วนใหญ่ไม่ต้องการแม้แต่จะย้อนกลับไปและจัดทำเอกสารพื้นที่ที่สับสน! มันใช้งานมากจริงๆ.
แต่ถ้าคุณสามารถเขียนความคิดเห็นในขณะที่คุณกำลังเขียนโปรแกรม ทุกสิ่งจะยังคงสดอยู่ในใจของคุณ. โดยทั่วไปแล้วนักพัฒนาจะติดอยู่กับปัญหาและเว็บเพื่อหาทางออกที่ง่ายที่สุด เมื่อคุณเข้าสู่ช่วงเวลาของยูเรก้าและแก้ปัญหาดังกล่าวมักจะมีช่วงเวลาที่ชัดเจนซึ่งคุณเข้าใจข้อผิดพลาดก่อนหน้านี้ นี่จะเป็น เวลาที่ดีที่สุด เพื่อแสดงความคิดเห็นที่เปิดกว้างและซื่อสัตย์เกี่ยวกับรหัสของคุณ.
นอกจากนี้ยังช่วยให้คุณคุ้นเคยกับการแสดงความคิดเห็นไฟล์ทั้งหมดของคุณ ระยะเวลาที่ต้องใช้ในการย้อนกลับไปและหาวิธีการทำงานของบางอย่างที่ใหญ่กว่านั้นหลังจากที่คุณได้สร้างฟังก์ชั่นแล้ว. ทั้งตัวคุณเองในอนาคตและเพื่อนร่วมทีมของคุณจะขอบคุณสำหรับการแสดงความคิดเห็นล่วงหน้า.
4. การจัดการกับข้อผิดพลาด Buggy
เราทุกคนไม่สามารถนั่งหน้าคอมพิวเตอร์เพื่อเขียนโค้ดได้หลายชั่วโมง ฉันคิดว่าเราสามารถลองได้ แต่ในบางจุดเราต้องนอนหลับ! คุณอาจจะต้องแยกส่วนกับรหัสของคุณสำหรับวันที่คุณสมบัติบางอย่างยังไม่ทำงาน ในสถานการณ์นี้เป็นสิ่งสำคัญที่คุณ แสดงความคิดเห็นโดยละเอียดเกี่ยวกับสถานที่ที่คุณทิ้งสิ่งไว้.
แม้หลังจากการนอนหลับที่แสนสดชื่นคุณอาจประหลาดใจกับความยากลำบากในการกลับเข้าสู่การเข้ารหัส ตัวอย่างเช่นหากคุณกำลังสร้างหน้าอัปโหลดภาพและต้องปล่อยให้มันไม่สมบูรณ์คุณ ควรแสดงความคิดเห็นเกี่ยวกับที่ที่คุณค้างไว้ในกระบวนการ. ภาพที่อัพโหลดและจัดเก็บอยู่ในหน่วยความจำชั่วคราวหรือไม่? หรือบางทีพวกเขาอาจไม่ได้รับการยอมรับในแบบฟอร์มการอัปโหลดหรืออาจแสดงไม่ถูกต้องในหน้าหลังจากอัปโหลด.
ข้อผิดพลาดในการแสดงความคิดเห็นมีความสำคัญเนื่องจากเหตุผลหลักสองประการ ก่อนอื่นคุณทำได้ เลือกจุดที่คุณค้างไว้ได้อย่างง่ายดาย และ ลองใหม่อีกครั้งที่ใจเพื่อแก้ไขปัญหา. และประการที่สองคุณสามารถ แยกความแตกต่างระหว่างเวอร์ชันใช้งานจริงของเว็บไซต์ของคุณกับพื้นที่ทดสอบ. โปรดจำไว้ว่าควรใช้ความคิดเห็น อธิบายว่าทำไมคุณถึงทำอะไรบางอย่าง, ไม่ว่ามันจะทำอะไร.
ข้อสรุป
การพัฒนาแอปพลิเคชันและซอฟต์แวร์ของเว็บเป็นการฝึกฝนที่สมบูรณ์แม้ว่าจะเป็นเรื่องยาก หากคุณเป็นหนึ่งในนักพัฒนาไม่กี่คนที่เข้าใจการสร้างซอฟต์แวร์อย่างแท้จริงดังนั้นการพัฒนาทักษะการเขียนโปรแกรมของคุณจึงเป็นสิ่งสำคัญ. การทิ้งความคิดเห็นเชิงพรรณนาเป็นเพียงการปฏิบัติที่ดีในระยะยาว, และคุณจะไม่มีวันเสียใจ!
หากคุณมีข้อเสนอแนะสำหรับการแสดงความคิดเห็นรหัสที่ชัดเจนโปรดแจ้งให้เราทราบในพื้นที่อภิปรายด้านล่าง!