คำนำ:
รูปแบบการเข้ารหัสของภาษาการเขียนโปรแกรมมีความสำคัญมากสำหรับซอฟต์แวร์การบำรุงรักษาระยะยาวโดยเฉพาะอย่างยิ่งในการทำงานเป็นทีม หากทีมใช้สไตล์การเข้ารหัสแบบครบวงจรและเป็นมาตรฐานสามารถปรับปรุงระดับการทำงานร่วมกันของทีมและประสิทธิภาพการทำงาน หัวใจสำคัญของคู่มือสไตล์การเขียนโปรแกรมคือกฎการจัดรูปแบบพื้นฐานที่กำหนดวิธีการเขียนโค้ดระดับสูง คู่มือนี้มาจากหนังสือ "การเขียน JavaScript" ตาม "ข้อกำหนดการเข้ารหัสภาษา Java" และข้อกำหนดการเขียนโปรแกรม JavaScript ของ Crockford รวมถึงประสบการณ์ส่วนตัวและความชอบส่วนตัวของ Nicbolas จุดประสงค์ในการเขียนบทความนี้คือการสร้างความประทับใจให้ลึกซึ้งยิ่งขึ้นและทำให้ผู้คนเข้าใจรูปแบบการเข้ารหัส JS มากขึ้นและปรับปรุงคุณภาพการเข้ารหัสของพวกเขา สำหรับข้อมูลเพิ่มเติมโปรดอ่าน "การเขียน JavaScript"
1. เยื้อง
ระดับของแต่ละแถวประกอบด้วย 4 ช่องว่างหลีกเลี่ยงการเยื้องโดยใช้แท็บ
// วิธีการเขียนที่ดีถ้า (จริง) {dosomething ();}2. ความยาวของแถว
แต่ละบรรทัดไม่ควรเกิน 80 อักขระ หากบรรทัดเกิน 80 อักขระควรแตกหลังจากผู้ให้บริการ บรรทัดถัดไปควรเพิ่มการเยื้องสองระดับ (8 อักขระ)
// วิธีการเขียนที่ดี dosomething (อาร์กิวเมนต์ 1, อาร์กิวเมนต์ 2, aegment3, อาร์กิวเมนต์ 4, อาร์กิวเมนต์ 5); // วิธีการเขียนที่ไม่ดี: dosomething เยื้อง (อาร์กิวเมนต์ 1, อาร์กิวเมนต์ 2, aegment3, อาร์กิวเมนต์ 4, อาร์กิวเมนต์ 5);
3. ค่าดั้งเดิม
สตริงควรใช้คำพูดสองเท่าและเก็บหนึ่งบรรทัดหลีกเลี่ยงการใช้สแลชเพื่อเริ่มต้นหนึ่งบรรทัดในสตริง
ตัวเลขควรใช้จำนวนเต็มทศนิยมและอัลกอริทึมทางวิทยาศาสตร์เป็นตัวแทนจำนวนเต็มจำนวนเต็มเลขฐานสิบหกหรือทศนิยมจุดทศนิยม อย่างน้อยหนึ่งหมายเลขควรถูกเก็บไว้ก่อนและหลังทศนิยม หลีกเลี่ยงการใช้ปริมาณคู่แปดเส้น
ควรหลีกเลี่ยงค่าโมฆะพิเศษยกเว้นในกรณีต่อไปนี้
•ใช้เพื่อเริ่มต้นตัวแปรซึ่งอาจกำหนดค่าให้กับวัตถุ
•ใช้เพื่อเปรียบเทียบกับตัวแปรที่เริ่มต้นซึ่งสามารถหรือไม่ใช่วัตถุ
•เมื่อคาดว่าพารามิเตอร์ของฟังก์ชันจะเป็นวัตถุมันจะถูกส่งผ่านเป็นพารามิเตอร์
•เมื่อค่าส่งคืนของฟังก์ชั่นคาดว่าจะเป็นวัตถุมันจะถูกส่งออกเป็นค่าส่งคืน
หลีกเลี่ยงการใช้ค่าพิเศษที่ไม่ได้กำหนด เพื่อตรวจสอบว่าควรใช้ตัวแปรหรือไม่ควรใช้ตัวดำเนินการประเภทของตัวดำเนินการ
4. ระยะห่างของผู้ประกอบการ
ต้องใช้พื้นที่ก่อนและหลังงบประมาณไบนารีเพื่อให้นิพจน์เรียบร้อย ผู้ประกอบการรวมถึงผู้ให้บริการที่ได้รับมอบหมายและผู้ให้บริการเชิงตรรกะ
// การเขียนที่ดีสำหรับ (var i = 0; i <count; i ++) {process (i);} // การเขียนที่ไม่ดี: พื้นที่ที่หายไปสำหรับ (var i = 0; i <count; i ++) {process (i);}5. ระยะห่างของวงเล็บ
เมื่อใช้วงเล็บไม่ควรมีที่ว่างทันทีหลังจากตัวยึดซ้ายและทันทีก่อนที่วงเล็บปิด
// การเขียนที่ดีสำหรับ (var i = 0; i <count; i ++) {process (i);} // การเขียนที่ไม่ดี: มีช่องว่างพิเศษทั้งสองด้านของพารามิเตอร์สำหรับ (var i = 0; i <count; i ++) {กระบวนการ (i);};6. การวัดวัตถุโดยตรง
ปริมาณโดยตรงของวัตถุควรมีรูปแบบต่อไปนี้
•ควรเก็บเครื่องมือจัดฟันซ้ายเริ่มต้นไว้ในบรรทัดเดียวกับนิพจน์
•ค่าชื่อของแต่ละแอตทริบิวต์ควรได้รับการเยื้องและแอตทริบิวต์แรกควรเป็นบรรทัดใหม่หลังจากรั้งหยิกซ้าย
•ค่าชื่อของแต่ละแอตทริบิวต์ควรใช้โดยไม่มีเครื่องหมายคำพูดตามด้วยลำไส้ใหญ่ (ก่อนช่องว่าง) ตามด้วยค่า
•หากค่าแอตทริบิวต์เป็นประเภทฟังก์ชันร่างกายควรเริ่มต้นบรรทัดใหม่ภายใต้ชื่อแอตทริบิวต์และควรเก็บสายเปล่าไว้ก่อนและหลัง
•เส้นเปล่าสามารถแทรกก่อนและหลังชุดคุณสมบัติที่เกี่ยวข้องเพื่อปรับปรุงความสามารถในการอ่านของรหัส
•รั้งขวาตอนจบควรครอบครองหนึ่งบรรทัดโดยเฉพาะ
// วิธีการเขียนที่ดี var object = {key1: value1, key2: value2, func: function () {// dosomething}, key3: value3}; // วิธีการเขียนที่ไม่ดี: วิธีการเขียนที่ไม่เหมาะสม {// dosomething}, key3: value3};เมื่อใช้ตัวอักษรวัตถุเป็นพารามิเตอร์ฟังก์ชันหากค่าเป็นตัวแปรการจัดฟันเริ่มต้นควรอยู่ในบรรทัดเดียวกับชื่อฟังก์ชัน กฎอื่น ๆ ที่ระบุไว้ก่อนหน้านี้ใช้เช่นกัน
// วิธีการเขียนที่ดี dosomething ({key1: value1, key2: value2}); // วิธีการเขียนที่ไม่ดี: รหัสทั้งหมด dosomething ({key1: value1, key2: value2});7. ความคิดเห็น
การใช้ความคิดเห็นที่กระชับและชัดเจนสามารถช่วยให้ผู้อื่นเข้าใจรหัสของคุณ ควรใช้ความคิดเห็นในสถานการณ์ต่อไปนี้
•รหัสไม่ชัดเจน
•รหัสที่อาจเข้าใจผิดว่าเป็นข้อผิดพลาด
•รหัสเฉพาะเบราว์เซอร์ที่จำเป็น แต่ไม่ชัดเจน
•สำหรับวัตถุวิธีการหรือคุณสมบัติจำเป็นต้องสร้างเอกสาร (โดยใช้ความคิดเห็นของเอกสารที่เหมาะสม)
ความคิดเห็นบรรทัดเดียว
ควรใช้ความคิดเห็นบรรทัดเดียวเพื่อแสดงรหัสหนึ่งบรรทัดหรือชุดของรหัสที่เกี่ยวข้อง อาจมีสามวิธีในการใช้ความคิดเห็นบรรทัดเดียว
•ความคิดเห็นพิเศษเพื่ออธิบายรหัสบรรทัดถัดไป
•ความคิดเห็นในตอนท้ายของบรรทัดของรหัสเพื่ออธิบายรหัสก่อน
•หลายบรรทัดเพื่อแสดงความคิดเห็นบล็อกของรหัส
// การเขียนที่ดีถ้า (เงื่อนไข) {// ถ้ารหัสถูกเรียกใช้ที่นี่หมายความว่าการตรวจสอบความปลอดภัยทั้งหมดได้ถูกส่งผ่าน;} // การเขียนที่ไม่ดี: ไม่มีบรรทัดว่างเปล่าก่อนที่ความคิดเห็นหาก (เงื่อนไข) {// // ถ้ารหัสถูกดำเนินการที่นี่หมายความว่าการตรวจสอบความปลอดภัยทั้งหมดได้ถูกส่งไปแล้ว ผ่าน;} // การเขียนที่ไม่ดี: ความคิดเห็นหลายบรรทัดควรใช้ // รหัสชิ้นนี้ใช้สำหรับ ** การตัดสิน // ถ้า (เงื่อนไข) {// ถ้ารหัสถูกดำเนินการที่นี่หมายความว่าการตรวจสอบความปลอดภัยทั้งหมดได้ถูกส่งผ่าน; ผ่านอนุญาต (); // ดำเนินการฟังก์ชัน **} // การเขียนไม่ดี: มีช่องว่างไม่เพียงพอระหว่างรหัสและความคิดเห็นหาก (เงื่อนไข) {// ถ้ารหัสถูกดำเนินการที่นี่หมายความว่าการตรวจสอบความปลอดภัยทั้งหมดได้รับอนุญาต (); // ดำเนินการฟังก์ชัน **} // การเขียนที่ดี: เมื่อแสดงความคิดเห็นบล็อกรหัสคุณควรติดต่อเพื่อใช้ความคิดเห็นบรรทัดเดียวและไม่ควรใช้ความคิดเห็นแบบหลายบรรทัดในกรณีนี้ // ถ้า (เงื่อนไข) {// อนุญาต (); // execute ** function //}ความคิดเห็นหลายบรรทัด
ควรใช้ความคิดเห็นแบบหลายบรรทัดเมื่อรหัสต้องการข้อความเพิ่มเติมเพื่อตีความ แต่ละความคิดเห็นหลายบรรทัดมีอย่างน้อยสามบรรทัดดังนี้:
1. บรรทัดแรกรวมถึงการเริ่มต้น /* ความคิดเห็นเริ่มต้นเท่านั้น ไม่ควรมีข้อความอื่นในบรรทัดนี้
2. บรรทัดต่อไปนี้เริ่มต้นด้วย * และยังคงอยู่ในแนวซ้าย สิ่งเหล่านี้สามารถอธิบายได้ด้วยคำพูด
3. บรรทัดสุดท้ายเริ่มต้นด้วย */ และยังคงอยู่ในแนวเดียวกันกับบรรทัดก่อนหน้า ไม่ควรมีข้อความอื่น
บรรทัดแรกของความคิดเห็นแบบหลายบรรทัดควรรักษาระดับการเยื้องในระดับเดียวกับที่อธิบายรหัส แต่ละบรรทัดที่ตามมาควรมีระดับการเยื้องและพื้นที่ที่แนบมา (เพื่อให้อักขระ * จัดเรียงอย่างถูกต้อง) ควรจองสายเปล่าก่อนแต่ละรหัสหลายบรรทัด
// วิธีการเขียนที่ดีถ้า (เงื่อนไข) {/** หากรหัสถูกดำเนินการที่นี่* หมายความว่าการตรวจจับความปลอดภัยทั้งหมดได้ถูกส่งผ่าน*/ อนุญาต ();}คำสั่งแสดงความคิดเห็น
บางครั้งความคิดเห็นสามารถใช้เพื่อประกาศข้อมูลเพิ่มเติมกับชิ้นส่วนของรหัส รูปแบบของคำสั่งเหล่านี้เริ่มต้นด้วยคำเดียวและตามด้วยลำไส้ใหญ่ทันที ข้อความที่สามารถใช้ได้มีดังนี้
TODO: รหัสคำอธิบายยังไม่เสร็จสมบูรณ์ ควรรวมสิ่งที่คุณต้องการทำต่อไป
แฮ็ค: มันแสดงให้เห็นว่าการใช้งานรหัสได้ใช้ทางลัด ควรรวมเหตุผลที่ใช้แฮ็ก สิ่งนี้อาจบ่งบอกว่าอาจมีทางออกที่ดีกว่าสำหรับปัญหา
XXX: อธิบายว่ารหัสเป็นปัญหาและควรได้รับการแก้ไขโดยเร็วที่สุด
FIXME: อธิบายว่ารหัสเป็นปัญหาและควรได้รับการแก้ไขโดยเร็วที่สุด มันเป็นวินาทีเล็กน้อยถึง xxx
รีวิว: รหัสคำสั่งจำเป็นต้องได้รับการตรวจสอบในการเปลี่ยนแปลงที่เป็นไปได้ใด ๆ
การประกาศเหล่านี้อาจใช้ในความคิดเห็นอย่างน้อยหนึ่งรายการและควรปฏิบัติตามกฎการจัดรูปแบบเดียวกันกับประเภทความคิดเห็นทั่วไป
8. การตั้งชื่อ
ตัวแปรและฟังก์ชั่นควรระมัดระวังเมื่อตั้งชื่อ การตั้งชื่อควรถูก จำกัด ไว้ที่อักขระตัวอักษรเชิงตัวเลขและขีดเส้นใต้ (_) สามารถใช้ในบางกรณี เป็นการดีที่สุดที่จะไม่ใช้เครื่องหมายดอลลาร์ ($) หรือ backslash (/) ในการตั้งชื่อใด ๆ
การตั้งชื่อตัวแปรควรอยู่ในรูปแบบการตั้งชื่ออูฐโดยมีตัวพิมพ์เล็กตัวอักษรตัวแรกและตัวอักษรตัวแรกของแต่ละคำว่าตัวพิมพ์ใหญ่ คำแรกของชื่อตัวแปรควรเป็นคำนาม (ไม่ใช่คำกริยา) เพื่อหลีกเลี่ยงความสับสนด้วยฟังก์ชั่นเดียวกัน อย่าใช้ขีดล่างในชื่อตัวแปร
// วิธีการเขียนที่ดี var accountNumber = "test001"; // วิธีการเขียนที่ไม่ดี: เริ่มต้นด้วยตัวอักษรตัวพิมพ์ใหญ่ var accountNumber = "test001"; // วิธีการเขียนที่ไม่ดี: เริ่มต้นด้วยคำกริยา var getAccountNumber = "test001"; // วิธีการเขียนที่ไม่ดี: ใช้ Underscore var account_number = "test001";
ชื่อฟังก์ชั่นควรอยู่ในรูปแบบการตั้งชื่ออูฐ คำแรกของชื่อฟังก์ชันควรเป็นคำกริยา (ไม่ใช่คำนาม) เพื่อหลีกเลี่ยงความสับสนกับตัวแปรเดียวกัน เป็นการดีที่สุดที่จะไม่ใช้ขีดล่างในชื่อฟังก์ชั่น
// วิธีการเขียนวิธีการเขียน dosomething () {// code} // วิธีการเขียนที่ไม่ดี: ฟังก์ชั่น dosomething () {// code} // วิธีการเขียนที่ไม่ดี: ฟังก์ชั่นบางอย่าง () {// code} // วิธีการเขียนที่ไม่ดี: ใช้ฟังก์ชั่น underscore do_something () {// รหัส}}ตัวสร้าง - ฟังก์ชั่นที่สร้างวัตถุใหม่ผ่านตัวดำเนินการใหม่ - ควรตั้งชื่อในรูปแบบอูฐและอักขระตัวแรกนั้นเป็นตัวพิมพ์ใหญ่ ชื่อคอนสตรัคเตอร์ควรเริ่มต้นด้วยไม่ใช่คำกริยาเนื่องจากใหม่แสดงถึงการทำงานของการสร้างอินสแตนซ์ของวัตถุ
// วิธีการเขียนที่ดีฟังก์ชัน myobject () {// code} // วิธีการเขียนที่ไม่ดี: ฟังก์ชัน myobject () ที่จุดเริ่มต้นของตัวอักษรตัวพิมพ์เล็ก {// code} // วิธีการเขียนที่ไม่ดี: ใช้ฟังก์ชั่น Underscore my_object () {// // code} // วิธีการเขียนที่ไม่ดี: ฟังก์ชั่นชื่อของค่าคงที่ (ตัวแปรที่ไม่มีค่าเปลี่ยน) ควรเป็นตัวอักษรตัวใหญ่ทั้งหมดคั่นด้วยขีดเส้นใต้เดียวระหว่างคำที่แตกต่างกัน
// วิธีการเขียนที่ดี var total_count = 10; // วิธีการเขียนที่ไม่ดี: รูปแบบอูฐ var totalCount = 10; // วิธีการเขียนที่ไม่ดี: รูปแบบผสม var total_count = 10;
คุณลักษณะของวัตถุนั้นเหมือนกับตัวแปร วิธีการของวัตถุเหมือนกับฟังก์ชัน หากคุณสมบัติหรือวิธีการเป็นส่วนตัวควรเพิ่มขีดล่างก่อนหน้านี้
// วิธีการเขียนที่ดี var object = {_count: 10,4 _getCount: function () {return this._count; -9. การประกาศตัวแปรและฟังก์ชั่น
การประกาศตัวแปร
ควรกำหนดตัวแปรทั้งหมดล่วงหน้าก่อนการใช้งาน คำจำกัดความของตัวแปรควรวางไว้ที่จุดเริ่มต้นของฟังก์ชั่นโดยใช้นิพจน์ VAR หนึ่งตัวแปรต่อบรรทัด ยกเว้นแถวแรกแถวทั้งหมดควรเยื้องเลเยอร์อีกหนึ่งชั้นเพื่อให้ชื่อตัวแปรสามารถจัดแนวในแนวตั้งได้ คำจำกัดความของตัวแปรควรเริ่มต้นและผู้ประกอบการที่ได้รับมอบหมายควรรักษาความเยื้องที่สอดคล้องกัน ตัวแปรเริ่มต้นควรเป็นก่อนที่ตัวแปรจะเริ่มต้น
// วิธีการเขียนที่ดี var count = 10, name = "jeri", found = false, ว่างเปล่า;
การประกาศฟังก์ชั่น
ควรกำหนดฟังก์ชั่นล่วงหน้าก่อนการใช้งาน ฟังก์ชั่นที่ไม่ใช่วิธีการ (นั่นคือไม่มีแอตทริบิวต์เป็นวัตถุ) ควรใช้รูปแบบที่กำหนดโดยฟังก์ชั่น (ไม่ใช่รูปแบบการแสดงออกของฟังก์ชั่นและฟังก์ชั่นตัวสร้าง) ไม่ควรมีช่องว่างระหว่างชื่อฟังก์ชั่นและวงเล็บเริ่ม ควรมีพื้นที่ว่างระหว่างวงเล็บตอนจบและวงเล็บหยิกทางด้านขวา วงเล็บปีกกาหยิกทางด้านขวาควรอยู่ในบรรทัดเดียวกับคำหลักของฟังก์ชั่น ไม่ควรมีช่องว่างระหว่างวงเล็บเริ่มต้นและจุดสิ้นสุด ควรมีพื้นที่ว่างหลังจากเครื่องหมายจุลภาคระหว่างชื่อพารามิเตอร์ ร่างกายฟังก์ชั่นควรเยื้องในระดับแรก
// วิธีการเขียนที่ดีฟังก์ชัน OUTER () {var count = 10, name = "Jeri", found = false, ว่างเปล่า; function inner () {// code} // รหัสที่เรียกว่า inner ()}}ฟังก์ชั่นที่ไม่ระบุชื่ออาจถูกกำหนดเป็นวิธีการกับวัตถุหรือเป็นพารามิเตอร์สำหรับฟังก์ชั่นอื่น ๆ ไม่ควรมีช่องว่างระหว่างคำหลักของฟังก์ชั่นและวงเล็บเริ่ม
// วิธีการเขียนที่ดี object.method = function () {// code}; // วิธีการเขียนที่ไม่ดี: อวกาศอวกาศที่ไม่ถูกต้อง method = function () {// code};ฟังก์ชั่นที่เรียกว่าทันทีควรห่อด้วยวงเล็บสวนที่ชั้นนอกของการเรียกใช้ฟังก์ชัน
// วิธีที่ดี var value = (function () {// function body return {ข้อความ: "hi"}} ());โหมดที่เข้มงวด
โหมดที่เข้มงวดควรใช้เฉพาะภายในฟังก์ชั่นและต้องไม่ใช้ทั่วโลก
// วิธีการเขียนที่ไม่ดี: ใช้โหมดที่เข้มงวด "ใช้อย่างเข้มงวด"; ฟังก์ชั่น dosomething () {// code} // วิธีการเขียนที่ดีฟังก์ชั่น dosomething () {"ใช้อย่างเข้มงวด"; // รหัส}10. ผู้ประกอบการ
งานที่มอบหมาย
เมื่อกำหนดค่าให้กับตัวแปรหากด้านขวาเป็นนิพจน์ที่มีคำสั่งเปรียบเทียบมันจะต้องถูกห่อหุ้มในวงเล็บ
// การเขียนที่ดี var flag = (i <count); // การเขียนที่ไม่ดี: วงเล็บที่ขาดหายไป var flag = i <count;
ตัวดำเนินการสัญญาณเท่ากัน
ใช้ === (เท่ากันอย่างเคร่งครัด) และ! == (ไม่เท่ากันอย่างเคร่งครัด) แทนที่จะเป็น == (เท่ากัน) และ! = (ไม่เท่ากัน) เพื่อหลีกเลี่ยงข้อผิดพลาดการแปลงประเภทที่อ่อนแอ
// การเขียนที่ดี var same = (a === b); // การเขียนที่ดี var same = (a == b);
ผู้ประกอบการสามคน
ผู้ประกอบการไตรภาคควรใช้เฉพาะในงบการกำหนดเงื่อนไขเท่านั้นและไม่ควรใช้แทนคำสั่งหากงบ
// วิธีการเขียนที่ดีค่า var ค่า = เงื่อนไข? Value1: value2; // วิธีการเขียนที่ไม่ดี: ไม่มีการกำหนดหากควรใช้นิพจน์หรือไม่? Dosomething (): Dosomethingelse;
11. คำสั่ง
คำสั่งง่ายๆ
แต่ละบรรทัดมีคำสั่งเดียวเท่านั้น ข้อความง่าย ๆ ทั้งหมดควรจบลงด้วยเครื่องหมายอัฒภาค (;)
// วิธีการเขียนที่ดีนับ ++; a = b; // วิธีการเขียนที่ไม่ดี: การแสดงออกหลายรายการถูกเขียนในหนึ่งบรรทัดนับ ++; a = b;
คำสั่งคืน
คำสั่งส่งคืนไม่ควรถูกห่อหุ้มด้วยวงเล็บเมื่อส่งคืนค่าเว้นแต่ในบางกรณีสิ่งนี้สามารถทำให้ค่าคืนได้ง่ายต่อการเข้าใจ ตัวอย่างเช่น:
return; return collection.size (); return (ขนาด> 0? ขนาด: ค่าเริ่มต้น);
คำสั่งผสม
คำสั่งผสมเป็นรายการของข้อความที่อยู่ในวงเล็บปีกกา
•คำสั่งที่แนบมาควรมีการเยื้องระดับหนึ่งมากกว่าคำสั่งผสม
•การจัดฟันเริ่มต้นควรอยู่ที่ส่วนท้ายของบรรทัดที่มีคำสั่งผสมอยู่ การจัดฟันปลายควรครอบครองหนึ่งบรรทัดและยังคงเยื้องเช่นเดียวกับจุดเริ่มต้นของคำสั่งผสม
•เมื่อคำสั่งเป็นส่วนหนึ่งของโครงสร้างการควบคุมเช่นถ้าหรือสำหรับคำสั่งข้อความทั้งหมดจำเป็นต้องมีการปิดล้อมในวงเล็บปีกการวมถึงคำสั่งเดียว การประชุมนี้ทำให้เราสามารถเพิ่มคำสั่งได้ง่ายขึ้นโดยไม่ต้องกังวลเกี่ยวกับการลืมเพิ่มวงเล็บและทำให้เกิดข้อบกพร่อง
•คำหลักสำหรับคำสั่งเช่นถ้าควรเริ่มต้นตามด้วยพื้นที่และการจัดฟันเริ่มต้นควรตามด้วยพื้นที่
ถ้าแถลงการณ์
คำสั่ง IF ควรอยู่ในรูปแบบต่อไปนี้
if (เงื่อนไข) {คำสั่ง} if (เงื่อนไข) {คำสั่ง} อื่น {คำสั่ง} ถ้า (เงื่อนไข) {คำสั่ง} อื่นถ้า (เงื่อนไข) {คำสั่ง} อื่น {คำสั่ง}มันไม่เคยได้รับอนุญาตให้ละเว้นการจัดฟันแบบหยิกถ้างบ
// การเขียนที่ดีถ้า (เงื่อนไข) {dosomething ();} // การเขียนที่ไม่ดี: ช่องว่างที่ไม่เหมาะสมถ้า (เงื่อนไข) {dosomething ();} // การเขียนที่ไม่ดี: รหัสทั้งหมดอยู่ในบรรทัดเดียวถ้า (เงื่อนไข) {dosomething (); } // การเขียนที่ไม่ดี: รหัสทั้งหมดอยู่ในบรรทัดเดียวและไม่มีการจัดฟันแบบหยิกถ้า (เงื่อนไข) dosomething ();สำหรับคำสั่ง
สำหรับคำสั่งประเภทควรอยู่ในรูปแบบต่อไปนี้
สำหรับ (การเริ่มต้น; เงื่อนไข; อัปเดต) {คำสั่ง} สำหรับ (ตัวแปรในวัตถุ) {คำสั่ง}ส่วนการเริ่มต้นของคำสั่ง FOR ไม่ควรมีการประกาศตัวแปร
// วิธีที่ดี var i, len; สำหรับ (i = 0, len = 0; i <len; i ++) {// code} // การเขียนที่ไม่ดี: ประกาศตัวแปรสำหรับ (var i = 0, len = 0; i <len; i ++) {// code} // การเขียนที่ไม่ดีเมื่อใช้คำสั่ง For-In อย่าลืมใช้ HasownProperty () สำหรับการตรวจสอบสองครั้งเพื่อกรองสมาชิกของวัตถุ
ในขณะที่คำสั่ง
ข้อความของคลาสขณะที่ควรอยู่ในรูปแบบต่อไปนี้
ในขณะที่ (เงื่อนไข) {คำสั่ง}ทำคำสั่ง
ข้อความของคลาส DO ควรอยู่ในรูปแบบต่อไปนี้
ทำ {คำสั่ง} ในขณะที่ (เงื่อนไข);คำสั่งเปลี่ยน
ข้อความของคลาสสวิตช์ควรอยู่ในรูปแบบต่อไปนี้
สวิตช์ (นิพจน์) {case นิพจน์: คำสั่งเริ่มต้น: คำสั่ง}กรณีแรกภายใต้สวิตช์ควรถูกเยื้อง ทุกกรณียกเว้นกรณีแรกรวมถึงค่าเริ่มต้นควรเก็บบรรทัดว่างไว้ก่อนหน้า
แต่ละชุดของคำสั่ง (ยกเว้นค่าเริ่มต้น) ควรจบลงด้วยการหยุดพักส่งกลับโยนหรือข้ามด้วยบรรทัดความคิดเห็น
// สวิตช์วิธีการเขียนที่ดี (ค่า) {กรณีที่ 1:/ * ตกผ่าน */ กรณีที่ 2: dosomething (); หยุดพัก; กรณีที่ 3: คืนจริง; ค่าเริ่มต้น: โยนข้อผิดพลาดใหม่ ("ข้อผิดพลาดบางอย่าง");}หากคำสั่งสวิตช์ไม่มีกรณีเริ่มต้นควรเปลี่ยนบรรทัดความคิดเห็น
// สวิตช์วิธีการเขียนที่ดี (ค่า) {กรณีที่ 1:/ * ตกผ่าน */ กรณีที่ 2: dosomething (); หยุดพัก; กรณีที่ 3: คืนจริง; ค่าเริ่มต้น: // ไม่มีค่าเริ่มต้น}ลองใช้คำสั่ง
ข้อความของคลาสลองควรจัดรูปแบบดังนี้
ลอง {คำสั่ง} catch (ตัวแปร) {คำสั่ง} ลอง {คำสั่ง} catch (ตัวแปร) {คำสั่ง} ในที่สุด {คำสั่ง}12. ทิ้งสีขาว
การเพิ่มบรรทัดที่ว่างเปล่าของรหัสระหว่างรหัสที่เกี่ยวข้องกับตรรกะสามารถปรับปรุงความสามารถในการอ่านของรหัส
สองเส้นเปล่าถูก จำกัด ให้ใช้ในสถานการณ์ต่อไปนี้:
•ระหว่างไฟล์ซอร์สโค้ดที่แตกต่างกัน
•ระหว่างคำจำกัดความของคลาสและอินเตอร์เฟส
เส้นเปล่าบรรทัดเดียวมีเฉพาะในกรณีต่อไปนี้
•ระหว่างวิธีการ
•ระหว่างตัวแปรท้องถิ่นในวิธีการและคำสั่งบรรทัดแรก
•ก่อนความคิดเห็นหลายบรรทัดหรือบรรทัดเดียว
•บล็อกรหัสโลจิคัลในวิธีการใช้เพื่อปรับปรุงความสามารถในการอ่านของรหัส
ควรใช้ช่องว่างในสถานการณ์ต่อไปนี้
•กรณีที่คำหลักตามด้วยวงเล็บควรคั่นด้วยช่องว่าง
•พื้นที่ควรเหลือหลังจากเครื่องหมายจุลภาคในรายการพารามิเตอร์
•ตัวถูกดำเนินการของผู้ให้บริการไบนารีทั้งหมดยกเว้นคะแนน (.) ควรคั่นด้วยช่องว่าง ตัวถูกดำเนินการของตัวดำเนินการ monolog ไม่ควรคั่นด้วยช่องว่างเช่นเครื่องหมายลบลบ, การเพิ่มขึ้น (++), การลดลง (-)
•การแสดงออกของคำสั่งสำหรับคำสั่งควรคั่นด้วยช่องว่าง
13. สิ่งที่ต้องหลีกเลี่ยง
•อย่าสร้างวัตถุใหม่โดยใช้ประเภท wrapper ดั้งเดิมเช่นสตริง
•หลีกเลี่ยงการใช้ Eval ()
•หลีกเลี่ยงการใช้กับข้อความ คำแถลงนี้ไม่มีอยู่ในโหมดที่เข้มงวดอีกต่อไปและอาจถูกลบออกในมาตรฐาน ECMAScript ในอนาคต
เขียนในตอนท้าย
คู่มือข้างต้นไม่ได้ติดตามอย่างเต็มที่ในระหว่างกระบวนการพัฒนา เราสามารถวาดบางส่วนของพวกเขาเพื่อปรับปรุงรูปแบบการเข้ารหัสของเราและทำให้รหัสของเราอ่านและบำรุงรักษาได้ เกี่ยวกับสไตล์การเข้ารหัสแต่ละทีมมีลักษณะของตัวเอง ตราบใดที่ทีมมีความสอดคล้องกันก็โอเคที่จะพัฒนาได้อย่างมีประสิทธิภาพ กฎบางอย่างไม่ใช่สิ่งที่เราต้องเชื่อฟังอย่างต่อเนื่อง ตัวอย่างเช่นในแง่ของการเยื้องเรามักจะใช้คีย์แท็บเพื่อความสะดวกมากขึ้น แต่เราไม่สามารถรับประกันได้ว่าแท็บหมายถึง 4 ช่องว่างในสภาพแวดล้อมใด ๆ เพื่อรักษาความสอดคล้องในการเยื้องหากใช้คีย์แท็บจะต้องใช้ตลอดกระบวนการ และเราไม่จำเป็นต้องใช้ "" และ "" และมันก็เป็นไปได้ที่จะใช้ "ตราบใดที่คุณรักษาสไตล์ที่สอดคล้องกันมีปัญหาสไตล์ที่คล้ายกันอื่น ๆ อีกมากมายทั้งหมดขึ้นอยู่กับตัวเลือกส่วนบุคคล
ไม่มีกฎที่สมบูรณ์แบบเฉพาะหรือไม่