โฮมเพจ » ออกแบบเว็บไซต์ » ความคิดเห็นเกี่ยวกับซอร์สโค้ดเคล็ดลับการกำหนดสไตล์และแนวทางปฏิบัติที่ดีที่สุด

    ความคิดเห็นเกี่ยวกับซอร์สโค้ดเคล็ดลับการกำหนดสไตล์และแนวทางปฏิบัติที่ดีที่สุด

    นักพัฒนาที่ใช้เวลาในโครงการขนาดใหญ่เข้าใจถึงความสำคัญของการแสดงความคิดเห็นเกี่ยวกับโค้ด เมื่อคุณสร้างคุณสมบัติมากมายในแอพพลิเคชั่นเดียวกันสิ่งต่าง ๆ มักจะมีความซับซ้อน มีบิตข้อมูลจำนวนมากรวมถึงฟังก์ชั่นการอ้างอิงตัวแปรค่าส่งคืนพารามิเตอร์ ... คุณคาดหวังที่จะรักษาอย่างไร?

    ไม่น่าแปลกใจเลยที่การแสดงความคิดเห็นรหัสของคุณเป็นสิ่งจำเป็นทั้งโครงการเดี่ยวและโครงการ แต่นักพัฒนาหลายคนไม่ทราบว่าจะทำอย่างไรกับกระบวนการนี้ ฉันได้แสดงกลวิธีส่วนตัวบางอย่างของฉัน การสร้างความคิดเห็นโค้ดที่จัดรูปแบบเรียบร้อย. เทมเพลตมาตรฐานและข้อคิดเห็นจะแตกต่างกันระหว่างนักพัฒนา แต่ท้ายที่สุดคุณควรพยายามทำ ทำความสะอาดและแสดงความคิดเห็น เพื่ออธิบายเพิ่มเติมเกี่ยวกับพื้นที่ที่สับสนในรหัสของคุณ.

    เราควรเริ่มพูดคุยเกี่ยวกับความแตกต่างบางประการในการจัดรูปแบบความคิดเห็น สิ่งนี้จะช่วยให้คุณมีความคิดที่ดีขึ้นว่ารายละเอียดของคุณจะเป็นอย่างไรกับรหัสโครงการ หลังจากนั้นฉันจะเสนอเคล็ดลับและตัวอย่างเฉพาะซึ่งคุณสามารถเริ่มใช้งานได้ทันที!

    สไตล์ความคิดเห็น: ภาพรวม

    ควรสังเกตว่าแนวคิดเหล่านี้นำเสนอเป็นเพียง แนวทาง ที่มีต่อความคิดเห็นที่สะอาด ภาษาการเขียนโปรแกรมส่วนบุคคลไม่ได้กำหนดแนวทางหรือข้อกำหนดสำหรับวิธีการตั้งค่าเอกสารของคุณ.

    ดังที่กล่าวไปแล้วผู้พัฒนาในยุคปัจจุบันได้รวมตัวกันเพื่อจัดรูปแบบระบบการแสดงความคิดเห็นโค้ดของตนเอง ฉันจะเสนอรูปแบบหลัก ๆ สองสามอย่างและดูรายละเอียดเกี่ยวกับวัตถุประสงค์ของพวกเขา.

    การแสดงความคิดเห็นแบบอินไลน์

    ทุกข้อเสนอภาษาการเขียนโปรแกรมเดียวจริง ความคิดเห็นแบบอินไลน์. สิ่งเหล่านี้ถูก จำกัด ไว้ที่เนื้อหาบรรทัดเดียวและแสดงความคิดเห็นข้อความหลังจากจุดที่แน่นอน ตัวอย่างเช่นใน 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

    เราทุกคนไม่สามารถนั่งหน้าคอมพิวเตอร์เพื่อเขียนโค้ดได้หลายชั่วโมง ฉันคิดว่าเราสามารถลองได้ แต่ในบางจุดเราต้องนอนหลับ! คุณอาจจะต้องแยกส่วนกับรหัสของคุณสำหรับวันที่คุณสมบัติบางอย่างยังไม่ทำงาน ในสถานการณ์นี้เป็นสิ่งสำคัญที่คุณ แสดงความคิดเห็นโดยละเอียดเกี่ยวกับสถานที่ที่คุณทิ้งสิ่งไว้.

    แม้หลังจากการนอนหลับที่แสนสดชื่นคุณอาจประหลาดใจกับความยากลำบากในการกลับเข้าสู่การเข้ารหัส ตัวอย่างเช่นหากคุณกำลังสร้างหน้าอัปโหลดภาพและต้องปล่อยให้มันไม่สมบูรณ์คุณ ควรแสดงความคิดเห็นเกี่ยวกับที่ที่คุณค้างไว้ในกระบวนการ. ภาพที่อัพโหลดและจัดเก็บอยู่ในหน่วยความจำชั่วคราวหรือไม่? หรือบางทีพวกเขาอาจไม่ได้รับการยอมรับในแบบฟอร์มการอัปโหลดหรืออาจแสดงไม่ถูกต้องในหน้าหลังจากอัปโหลด.

    ข้อผิดพลาดในการแสดงความคิดเห็นมีความสำคัญเนื่องจากเหตุผลหลักสองประการ ก่อนอื่นคุณทำได้ เลือกจุดที่คุณค้างไว้ได้อย่างง่ายดาย และ ลองใหม่อีกครั้งที่ใจเพื่อแก้ไขปัญหา. และประการที่สองคุณสามารถ แยกความแตกต่างระหว่างเวอร์ชันใช้งานจริงของเว็บไซต์ของคุณกับพื้นที่ทดสอบ. โปรดจำไว้ว่าควรใช้ความคิดเห็น อธิบายว่าทำไมคุณถึงทำอะไรบางอย่าง, ไม่ว่ามันจะทำอะไร.

    ข้อสรุป

    การพัฒนาแอปพลิเคชันและซอฟต์แวร์ของเว็บเป็นการฝึกฝนที่สมบูรณ์แม้ว่าจะเป็นเรื่องยาก หากคุณเป็นหนึ่งในนักพัฒนาไม่กี่คนที่เข้าใจการสร้างซอฟต์แวร์อย่างแท้จริงดังนั้นการพัฒนาทักษะการเขียนโปรแกรมของคุณจึงเป็นสิ่งสำคัญ. การทิ้งความคิดเห็นเชิงพรรณนาเป็นเพียงการปฏิบัติที่ดีในระยะยาว, และคุณจะไม่มีวันเสียใจ!

    หากคุณมีข้อเสนอแนะสำหรับการแสดงความคิดเห็นรหัสที่ชัดเจนโปรดแจ้งให้เราทราบในพื้นที่อภิปรายด้านล่าง!