สิ่งที่ควรอยู่ในมาตรฐานการเข้ารหัส? [ปิด]

สิ่งที่ควรเป็นมาตรฐานการเข้ารหัสที่ดี (อ่าน: มีประโยชน์)

• สิ่งที่รหัสควรมี
• สิ่งที่รหัสไม่ควรมี
• มาตรฐานการเข้ารหัสควรมีคำจำกัดความของสิ่งที่ภาษาคอมไพเลอร์หรือตัวจัดรูปแบบโค้ดบังคับใช้หรือไม่?
• สิ่งที่เกี่ยวกับการวัดเช่นความซับซ้อนของวงจรเส้นต่อไฟล์ ฯลฯ

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

แท็บ vs Spaces! ฉันได้รับการอัปเดตอย่างบ้าคลั่งเมื่อเพื่อนร่วมงานคนหนึ่งของฉันยอมรับแท็บจำนวนมากเพื่อเปลี่ยนช่องว่างในที่เก็บ

อนุสัญญาการตั้งชื่อ

แก้ไข:จากนี้ฉันหมายถึงแนวทางการตั้งชื่อไม่ใช่การตั้งชื่อกฎ

All boolean values should begin with Is/Can/Has/etc when possibleยกตัวอย่างเช่นจะเป็นแนวทาง กฎจะเป็นAll boolean values must start with Is

มาตรฐานการเข้ารหัสสำหรับกลุ่มควรมีตัวเลือกคอมไพเลอร์สำหรับคำเตือนและข้อผิดพลาดที่ต้องแก้ไข

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

มาตรฐานดังกล่าวจะต้องกล่าวถึงวิธีที่โปรแกรมเมอร์สามารถปิดการใช้งานคำเตือนดังกล่าวได้เป็นกรณี ๆ ไปหากมีรหัสชิ้นพิเศษที่ไม่เป็นไปตามนั้น

มาตรฐานบางอย่างที่ฉันชอบ (ฉันรู้ว่ามีพวกเขามากมาย แต่นั่นคือสิ่งที่ฉันชอบ):

• ครอบคลุมการทดสอบ 80% ยูนิต
• ความเป็นเจ้าของโดยรวมของรหัส (เขียนโค้ดเพื่อให้เพื่อนร่วมทีมของคุณอ่านไม่ใช่คอมไพเลอร์)
• เขียนความคิดเห็น เขียนสิ่งที่คุณจะพูดกับผู้มาใหม่
• ง่าย ๆ เข้าไว้

มาตรฐานการเข้ารหัสช่วยได้เล็กน้อยเมื่อคุณเขียนรหัสในครั้งแรกพวกเขาช่วยได้มาก เมื่อคุณหรือผู้แทนที่ของคุณต้องอัปเดตโค้ด 2 ปีต่อมา

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

• ชื่ออธิบายอย่างชัดเจนถึงข้อมูลที่ถูกจัดการ
• วงเล็บปีกกาทำให้การไหลของการควบคุมชัดเจน
• ความคิดเห็นอธิบายอัลกอริทึมที่ไม่ชัดเจนใด ๆ ฯลฯ

ในทางกลับกันมาตรฐานที่กำหนดเองจำนวนมากเกินไปอาจรบกวนการเขียนโค้ด ดังนั้นฉันเชื่อว่าทุกรายการในรูปแบบการเข้ารหัสที่เสนอควรได้รับการประเมินตามเกณฑ์ 2 ข้อนี้:

• กฎนี้ช่วยให้แน่ใจว่ารหัสถูกต้องหรือไม่
• กฎนี้ช่วยให้มั่นใจได้หรือไม่ว่ารหัสนั้นชัดเจน ?

หากไม่เป็นจริงรายการนั้นเป็นเพียงการกำหนดเองและอาจไม่จำเป็น

ฉันจะรวมสิ่งต่อไปนี้ในมาตรฐานที่ฉันเขียน:

สำหรับความชัดเจน:

• การจัดระเบียบไฟล์: การระบุคำสั่งคงที่สำหรับรายการในไฟล์ช่วยให้ทีมสามารถนำทางไฟล์อื่น ๆ ได้อย่างง่ายดาย คุณไม่จำเป็นต้องตามล่าเพื่อหา #defines หรือนิยามโครงสร้าง

• แบบแผนการตั้งชื่อ: การตั้งชื่ออย่างสม่ำเสมอช่วยให้สามารถอ่านได้ แต่หลีกเลี่ยงกฎที่ระบุมากเกินไปซึ่งเป็นอันตรายต่อความสามารถในการเขียน

• โครงสร้างรหัส ตำแหน่งของ Brace Brace, ระดับการเยื้อง, ช่องว่างและแท็บ ฯลฯ ใช่สิ่งนี้อาจเป็นความชอบส่วนบุคคลที่แข็งแกร่ง แต่เป้าหมายคือรหัสที่ชัดเจน ค้นหาตัวเลือกที่ดีที่สุดสำหรับทีมและติดกับมัน

เพื่อความถูกต้อง:

• แนวทางปฏิบัติที่ดีที่สุดสำหรับประเภทปัญหาของคุณ: กฎเกี่ยวกับการจัดสรรหน่วยความจำหรือการทำงานพร้อมกันหรือการพกพา

• "Const Correctnesss" การใช้งานที่เหมาะสมstaticและvolatileอื่น ๆ

• กฎเกี่ยวกับมาโครตัวประมวลผลล่วงหน้าและคุณสมบัติที่ไม่เหมาะสมอื่น ๆ ของภาษา

ความคิดที่สร้างแรงบันดาลใจในทางปฏิบัติที่ทำให้คนคิดมากกว่าข้อ จำกัด เชิงลบที่หยุดคนคิด

มิฉะนั้นคุณจะได้รับรหัสลิงที่มีความกลัวที่จะไปหลังจากที่กล้วย

สิ่งที่ควรอยู่ในมาตรฐานการเข้ารหัส? น้อยที่สุด ค่อนข้างน้อยมากกว่า และด้วยเหตุผลความกรุณา

ไม่ใช่เพราะฉันเป็นผู้ทำโคบาลคาวบอยที่ไม่ต้องการกระบวนการ แต่เพราะฉันเห็นรายละเอียดการเข้ารหัสที่หนักหน่วงโดยไม่มีเหตุผลเกินกว่า (สมมุติ) "ฉันพบสิ่งนี้ใน 'Net ที่ไหนสักแห่งในปี 95' ที่เพิ่งจะกลายเป็น ฝันร้ายของข้าราชการที่จะทำงานกับ

บางคนดูเหมือนจะเชื่ออย่างสุจริตว่าการเพิ่มมาตรฐานพวกเขาจะเห็นการเพิ่มขึ้นของ "คุณภาพ" และการวัดที่พวกเขาจะทำได้ ในขณะเดียวกันพวกเขาจะเพิกเฉยต่อสถาปัตยกรรม, ประสิทธิภาพ, สามัญสำนึกและสิ่งอื่น ๆ ที่จบลงที่สำคัญมากกว่าจำนวนบรรทัดในไฟล์

ขั้นตอนสำหรับการตรวจสอบโค้ดเพื่อบังคับใช้มาตรฐาน โอ้และเพื่อหาข้อบกพร่องด้วย

สามัญสำนึกที่ดีบางอย่างจะไม่ผิดพลาด มีเอกสารมาตรฐานการเข้ารหัสจำนวนมากเกินไปที่ใช้กับจุดที่ไม่เกี่ยวข้อง (รายการเช่นประเภทแบบอักษรและขนาดเป็นหนึ่งในจำนวนที่มากที่สุดที่ฉันเคยเห็น)

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

ในตอนท้ายของวันรหัสที่ชัดเจนและเข้าใจได้มีความสำคัญมากกว่ากฎเข้มงวดเกี่ยวกับรูปแบบหรือตัวอักษร

ตามที่คนอื่น ๆ ได้กล่าวถึงการครอบคลุมการทดสอบรหัสเป็นสิ่งสำคัญ ฉันชอบที่จะเห็น:

• โครงสร้างโครงการ การทดสอบเป็นส่วนหนึ่งของรหัสหรืออยู่ในโครงการ / แพ็คเกจ / ไดเรกทอรีแยกกันหรือไม่ รหัส UI มีชีวิตอยู่กับส่วนหลังหรือไม่? ถ้าไม่เป็นเช่นนั้น

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

• การจัดการรหัสที่มา สิ่งที่ได้รับการตรวจสอบเมื่อ? เอกสารการออกแบบและแผนการทดสอบมีการควบคุมแก้ไขหรือไม่? คุณจะแยกสาขาเมื่อไหร่และเมื่อไหร่คุณจะแท็ก คุณสร้างงานสร้างก่อนหน้านี้หรือไม่และถ้านานเท่าไหร่ / นานเท่าไหร่?

• มาตรฐานการปรับใช้ บิวด์แพ็กเกจเป็นอย่างไร? ต้องมีอะไรบ้างในบันทึกย่อประจำรุ่น สคริปต์อัพเกรดถูกสร้าง / ควบคุม / รันอย่างไร

ลืมทุกสิ่งที่เกี่ยวกับการตั้งชื่อแบบแผนการจัดรูปแบบและจำนวนบรรทัดที่สามารถอยู่ในฟังก์ชั่น / เมธอด / โมดูล กฎข้อหนึ่ง: ใช้สิ่งที่มีสไตล์อยู่ในสิ่งที่คุณกำลังแก้ไข หากคุณไม่ชอบสไตล์ของใครบางคนให้แยกออกจากกันในการตรวจสอบรหัส ข้อยกเว้นเพียงอย่างเดียวอาจเป็นสิ่งที่แท็บ -sx- ช่องว่างถ้าเพียงเพราะบรรณาธิการ / IDE หลายคนจะแปลงหนึ่งไปยังอีกคนสุ่มสี่สุ่มห้าแล้วคุณปิดท้ายทำลายประวัติศาสตร์การเปลี่ยนแปลงของคุณเพราะทุกบรรทัดมีการเปลี่ยนแปลง

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

• ด้านเทคนิค: ซึ่งมีจุดมุ่งหมายเพื่อหลีกเลี่ยงรหัสที่มีความเสี่ยงหรือไม่ดี (แม้ว่าจะได้รับการยอมรับจากคอมไพเลอร์ / ล่าม)
• ด้านการนำเสนอ: ซึ่งเกี่ยวข้องกับตัวเองด้วยการทำให้โปรแกรมชัดเจนต่อผู้อ่าน

ด้านเทคนิคฉันมีสิทธิ์ของการเข้ารหัสมาตรฐานเช่นเดียวกับสมุนไพร Sutterและอังเดร Alexandrescuกับพวกเขาc ++ มาตรฐานการเข้ารหัส งานนำเสนอที่ฉันมีสิทธิ์ได้รับรูปแบบการเข้ารหัสซึ่งรวมถึงแบบแผนการตั้งชื่อการเยื้อง ฯลฯ ...

มาตรฐานการเข้ารหัส

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

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

เหตุผลและข้อยกเว้นมีความสำคัญมากเนื่องจากพวกเขาสรุปว่าทำไมและเมื่อใด

ชื่อเรื่องจะต้องชัดเจนเพียงพอว่าในระหว่างการตรวจทานเราจะต้องมีรายการชื่อเรื่อง (แผ่นงานโกง) เพื่อทำงานด้วยเท่านั้น และจัดกลุ่มรายการตามหมวดหมู่เพื่อให้ง่ายต่อการค้นหา

Sutter และ Alexandrescu มีรายชื่อเพียงร้อยรายการเท่านั้นแม้ว่า C ++ จะมีขนดก;

สไตล์การเข้ารหัส

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

คุณไม่ต้องการที่จะเข้าสู่สงครามศักดิ์สิทธิ์เกี่ยวกับรูปแบบการเยื้องหรือการรั้งที่ดีกว่าที่นี่มีฟอรัมสำหรับสิ่งนี้: ดังนั้นในหมวดหมู่นี้คุณทำสิ่งต่าง ๆ โดยฉันทามติ> โหวตเสียงข้างมาก> การตัดสินใจโดยผู้นำโดยพล

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

สำหรับหลักการตั้งชื่อฉันจะพยายามทำให้ class / types แตกต่างจากตัวแปร / คุณสมบัติได้อย่างง่ายดาย

นอกจากนี้ยังอยู่ในหมวดหมู่นี้ที่ฉันจัดหมวดหมู่ "การวัด" ที่ชอบ:

• ชอบวิธีการสั้นและยาว: มักจะยากที่จะเห็นด้วยกับสิ่งที่นาน
• ชอบกลับเร็ว / ต่อ / หยุดเพื่อลดการเยื้อง

อื่น ๆ ?

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

แต่สิ่งเหล่านี้จะไม่เกิดขึ้นหากไม่ได้ใช้และบังคับใช้จริง

การละเมิดใด ๆ ที่จะเกิดขึ้นในระหว่างการตรวจสอบรหัสและไม่ควรมีการตรวจสอบรหัสหากมีการละเมิดที่โดดเด่น:

• แก้ไขรหัสเพื่อให้ตรงกับกฎ
• แก้ไขกฎเพื่อให้รหัสไม่โดดเด่นอีกต่อไป

เห็นได้ชัดว่าการเปลี่ยนกฎหมายถึงการได้รับ "ไปข้างหน้า" จากผู้นำ

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

นี่คือตัวอย่างในส่วนการใช้อินเทอร์เฟซสมาชิกชัดแจ้งว่ามีรายการต่อไปนี้ (หมายเหตุฉันทิ้งเหตุผลเพื่อประโยชน์ของ bervity)

หลีกเลี่ยงการใช้สมาชิกอินเตอร์เฟสอย่างชัดเจนโดยไม่มีเหตุผลอันสมควรที่จะทำเช่นนั้น

พิจารณาการนำสมาชิกอินเตอร์เฟสไปใช้อย่างชัดเจนหากสมาชิกตั้งใจที่จะถูกเรียกผ่านทางอินเตอร์เฟสเท่านั้น

อย่าใช้สมาชิกที่ชัดเจนเป็นขอบเขตความปลอดภัย

จัดทำสมาชิกเสมือนที่ได้รับการปกป้องซึ่งมีฟังก์ชันการทำงานเช่นเดียวกับสมาชิกที่นำไปใช้อย่างชัดเจนหากฟังก์ชันนั้นมีความหมายเฉพาะสำหรับคลาสที่ได้รับมา

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

ดูเหมือนว่าไม่มีใครพูดถึงความปลอดภัย - ในมาตรฐานการเข้ารหัสคุณต้องมีการอ้างอิงถึงข้อกำหนดด้านความปลอดภัยของรหัส (เช่นการใช้โมดูลการตรวจสอบความถูกต้องของอินพุต, ไม่อนุญาตให้ใช้ฟังก์ชั่นที่อ่อนแอเช่น strcpy, ข้อกำหนดการจัดการข้อผิดพลาด ฯลฯ )

ตัวอย่าง. มีการจัดเรียงอย่างเรียบร้อยไม่ใช่เรื่องไร้สาระใกล้กับโลกแห่งความจริงที่ใช้ประโยชน์จากกฎทุกข้อ ความคิดเห็น (ไม่จำเป็นต้องเป็นส่วนหนึ่งของรหัส) ส่วนใดของตัวอย่างตามกฎใด

แม่แบบ ไม่ใช่ประเภท C ++ แต่เป็นสิ่งที่คัดลอกและเติมด้วย live มันง่ายกว่ามากที่จะได้รับความคิดเห็นสำเร็จรูป 24 บรรทัดเมื่อคุณมีการอ้างอิงเพื่อคัดลอก

คุณสมบัติหมายเลขหนึ่ง: สูงสุดสองหน้า

นี่คือสิ่งที่คุณต้องการให้นักพัฒนาซอฟต์แวร์ทุกคนอ่านและจดจำ คุณไม่จำเป็นต้องค้นหาในมาตรฐานทุกครั้งที่คุณจำเป็นต้องเขียนฟังก์ชั่นใหม่ (หรือแย่กว่าบรรทัดใหม่) ดังนั้นให้สั้นและรักษากฎที่ให้มูลค่าเพิ่มกับผลิตภัณฑ์ขั้นสุดท้ายเท่านั้น

มาตรฐานการเข้ารหัสมีหลายรายการจริง ๆ :

อนุสัญญาการเข้ารหัส

• สิ่งเหล่านี้ไม่จำเป็นต้องมีเหตุผลอื่นจากนั้น "ความมั่นคงของรหัสฐาน" สำหรับอดีต เพื่อใช้ '_' ในตัวแปรสมาชิกส่วนตัวหรือไม่
• อาจมีวิธีการที่ถูกต้องหลายวิธี เพียงแค่ต้องเลือกอย่างใดอย่างหนึ่งเพื่อความมั่นคง สำหรับอดีต การจัดการข้อผิดพลาดโดยใช้ข้อยกเว้นหรือรหัสข้อผิดพลาด

ปฏิบัติที่ดีที่สุด

• รายการเหล่านี้จำเป็นต้องมีเหตุผลที่ดีพร้อมตัวอย่างที่ชัดเจน

สำหรับอดีต อย่าปล่อยให้จับเปล่าหลังจากลอง

try { Foo(); } catch { //do nothing }

1) หากมีข้อยกเว้นเกิดขึ้นจาก Foo () อาจทำให้เกิดปัญหาอื่น ๆ เกี่ยวกับฟังก์ชั่นที่ตามมานั่นถือว่าสันนิษฐานว่า foo นั้นประสบความสำเร็จ

2) ตัวจัดการข้อผิดพลาดทั่วโลกจะไม่แจ้งให้ทีมสนับสนุนของข้อยกเว้นเมื่อมันเกิดขึ้นในแยง

• ครอบคลุมการปฏิบัติของ "การป้องกันการเข้ารหัส" เช่นการใช้ Asserts เพื่อทดสอบสมมติฐานของคุณ

สภาพแวดล้อมการเข้ารหัส

• เครื่องมือที่ทั้งทีมใช้ สำหรับอดีต VS 2010, Resharper, Kiln และอื่น ๆ

มาตรฐานการเข้ารหัสเมื่อเขียนบนกระดาษนั้นมีประสิทธิภาพมากเท่านั้น ฉันชอบวิธีที่ Go กำลังเผยแพร่มาตรฐานการเข้ารหัส มันมีเครื่องมือgofmtในการจัดรูปแบบข้อความโปรแกรมในรูปแบบ การอภิปรายเกี่ยวกับรูปแบบการเข้ารหัสใด ๆ gofmtจากนั้นก็จะส่งผลให้เป็นแพทช์แหล่งที่มาของการที่

สำหรับรูปแบบที่ควรมี

• วิธีตั้งชื่อตัวแปรแมโครค่าคงที่ตัวอักษรฟังก์ชัน ฯลฯ
• วิธีการวาง {,}, (,), [,] เมื่อมันมาถึงif, ฟังก์ชั่นร่างกาย, บล็อกคำสั่งสำหรับวัตถุประสงค์อื่น ๆ ,
• ความกว้างของการเยื้อง
• จำนวนบรรทัดของข้อความที่ใช้ได้
• มีกี่ระดับของการเยื้องที่ได้รับอนุญาตก่อนที่รหัสจะถูกปฏิเสธ / ส่งเพื่อทำการปรับเปลี่ยนใหม่
• จำนวนบรรทัดของรหัสที่ได้รับอนุญาตต่อฟังก์ชั่นก่อนที่มันจะถูกส่งกลับเพื่อ refactoring
• จำนวนอาร์กิวเมนต์สูงสุดที่ฟังก์ชันสามารถรับได้ก่อนที่จะถูกส่งกลับเพื่อทำการปรับโครงสร้างใหม่
• ความคิดเห็นสองสามบรรทัดก่อนที่ฟังก์ชันจะเริ่มอธิบายสั้น ๆ ว่ามันทำอะไรถ้าร่างกายต้องมีโค้ดหน้าจอเกินหนึ่งหน้า ปล่อยให้วัตถุบรรลุรหัสในส่วนของฟังก์ชัน

เมื่อฉันกำลังอ่านโค้ด (ภาษา C เป็นส่วนใหญ่) ของผู้อื่นหากชื่อตัวแปร / ฟังก์ชั่นไม่ง่ายในบริบทของโครงการหรือถ้าเกินกว่าห้าระดับของการเยื้องหรือฟังก์ชั่นใช้เวลามากกว่าหกหรือเจ็ดข้อโต้แย้งหรือฟังก์ชั่น สองหรือสามหน้าบนหน้าจอมันยากมากที่จะอ่านและทำความเข้าใจโค้ด เมื่อถูกขอให้ทำการปรับปรุง / บำรุงรักษามันจะเพิ่มความยากลำบากเท่านั้น มันทำให้ฉันต้องการgofmtเขียนโปรแกรมสำหรับทุกโครงการ (หรือแม้แต่ภาษา) และไฟล์ซอร์สโค้ดทุกไฟล์จะถูกเรียกใช้ผ่านโปรแกรมนั้นก่อนที่มันจะถูกส่งเข้าสู่โปรเจ็กต์

ผมชอบคู่มือสไตล์ Google JavaScript

มันกระชับในแนวทางของมันยังมีรายละเอียดหากคุณต้องการพวกเขา

รหัสเอกสารด้วยตนเอง (ความคิดเห็นชื่อตัวแปรชื่อฟังก์ชั่น ฯลฯ )