แนวทางการจัดรูปแบบโค้ดมีความสำคัญมากเพียงใด [ปิด]

มาตรฐานการเข้ารหัสเป็นเรื่องธรรมดาในองค์กรพัฒนาซอฟต์แวร์ใด ๆ แต่พวกเขามีความสำคัญต่อการปฏิบัติตามอย่างไร ฉันสามารถเข้าใจความต้องการความสอดคล้องบางอย่าง แต่เมื่อจัดการกับสิ่งง่าย ๆ เช่นตำแหน่งของเครื่องมือจัดฟัน, ความยาวของสาย ฯลฯ ฉันไม่แน่ใจว่ามาตรฐานที่เข้มงวดมากเกินไปมีส่วนช่วยในการพัฒนาซอฟต์แวร์มาก

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

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

หวังว่าทุกคนจะเขียนบทความเป็นภาษาอังกฤษ (หรือภาษาเดียวกัน) แต่สไตล์ที่แตกต่างจะชัดเจน บางคนจะเขียนได้ดีคนอื่นไม่ได้ บางคนจะใช้การหดตัวบางคนจะสะกดคำออกอย่างเต็มที่ (ตัวอย่าง: มัน verus มันคือ) เป็นต้น

ฉันคิดว่าคุณสัมผัสกับประเด็นที่สำคัญที่สุด:

1. มันเป็นแนวทาง
2. การอ่าน

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

ฉันไม่เคยอยู่ในร้านที่ฉันมีความสุขกับรูปแบบการเขียนโค้ดหรือการจัดรูปแบบของนักพัฒนาคนอื่น (อย่างน้อยเพราะมันไม่เหมือนกับของฉัน) แต่ฉันจะพอใจถ้าฉันสามารถอ่าน / เข้าใจและถ้ามันสอดคล้องกัน ทุกอย่างอื่นคือน้ำตาลบนน้ำตาลประโยค

ดังนั้นเพื่อตอบคำถามของคุณ: ค่อนข้างสำคัญ แต่แน่นอนว่าไม่ใช่จุดจบของโลกหากพวกเขาไม่ทำ

สำหรับมาตรฐานการจัดรูปแบบฉันทำตามสิ่งที่คนอื่นกำลังทำ หากพวกเขาใช้ PascalCase กับทุกสิ่งฉันก็จะใช้ PascalCase หากพวกเขาใช้ _camelCase ฉันก็จะใช้ _camelCase ทำไม? เพราะมัน จำกัด ปริมาณการจัดรูปแบบที่ฉันทำและ จำกัด สิ่งที่คนอื่นต้องทำเพื่อให้มัน "ดูดี" มาตรฐานการจัดรูปแบบมักจะมีเพื่อให้ทุกอย่างง่ายขึ้นสำหรับทุกคน

ที่งานปัจจุบันของฉันหนึ่งในภารกิจแรกของฉันคือการสร้างมาตรฐานการเข้ารหัสสำหรับกลุ่มการพัฒนาของเรา

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

มันไม่เคยเป็นลูกบุญธรรม

ทำไม? เพราะฉันทำงานกับคนเก่ง ๆ หลายคนผู้ซึ่งปฏิบัติตามมาตรฐานการเข้ารหัสที่สมเหตุสมผลแล้วโดยสัญชาตญาณ

ในส่วนของฉันฉันปฏิบัติตามแนวทางที่ยอมรับโดยทั่วไปจาก Microsoft และเลียนแบบรูปแบบที่ใช้กันทั่วไปของผู้อื่น (Javascript และ jQuery ถูกจัดรูปแบบแตกต่างจาก C # ถึงแม้ว่าพวกเขาจะเป็นทั้งภาษาที่มีความโค้ง) ฉันทำผิดกฎเป็นครั้งคราวเมื่อทำเช่นนั้นจะทำให้โค้ดอ่านง่ายขึ้น

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

สิ่งที่คนคนหนึ่งอ่านได้มากที่สุดจะไม่เป็นสำหรับทุกคน

หากคุณไม่ได้ใช้ IDE ประเภทนี้จะได้รับหนึ่งรายการ แม้แต่การคิดเรื่องนี้นานกว่า 10 นาทีก็เป็นการสิ้นเปลืองทรัพยากร IMHO

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

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

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

แนวทางหนึ่งที่ฉันใช้เมื่อพัฒนาหรืออัปเดตรูปแบบการเข้ารหัสของเราคือหลักการของการจัดกลุ่ม Gestalt - http://en.wikipedia.org/wiki/Gestalt_psychology#Gestalt_laws_of_grouping

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

if(true)
{
}

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

ไม่ว่าคุณจะใช้ภาษาหรือเครื่องมือใดมาพร้อมกับบางสิ่ง กำหนดค่า IDE ของคุณและตรวจสอบในไฟล์กำหนดค่า

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

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

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

แนวทางช่วยปรับปรุงคุณภาพของรหัส:

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

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

ไม่มีมาตรฐานสากลสำหรับสิ่งที่ทีมควรทำหรือไม่ควรทำ บางทีมต้องปฏิบัติตามแนวทางที่เข้มงวด แต่บางทีมก็ไม่ทำเช่นนั้น

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

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