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

ในขณะที่ฉันกำลังอ่านคำถามนี้คำตอบที่ได้รับการโหวตสูงสุดอ้างถึงลุง Bob เกี่ยวกับมาตรฐานการเขียนโค้ดแต่ฉันรู้สึกสับสนกับคำแนะนำนี้:

3. อย่าจดลงไปหากคุณสามารถหลีกเลี่ยงได้ ค่อนข้างปล่อยให้รหัสเป็นวิธีที่มาตรฐานถูกจับ

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

ทำไมฉันไม่ควรเขียนมาตรฐานการเข้ารหัสลงไป?

มีสาเหตุบางประการ

1. ไม่มีใครอ่านเอกสาร
2. ไม่มีใครติดตามเอกสารแม้ว่าพวกเขาจะอ่าน
3. ไม่มีใครอัปเดตเอกสารแม้ว่าพวกเขาจะอ่านและปฏิบัติตาม
4. การเขียนรายการปฏิบัติมีประสิทธิภาพน้อยกว่าการสร้างวัฒนธรรม

มาตรฐานการเข้ารหัสไม่เกี่ยวกับสิ่งที่ผู้คนควรทำ แต่เกี่ยวกับสิ่งที่พวกเขาทำจริงๆ เมื่อผู้คนเบี่ยงเบนจากมาตรฐานสิ่งนี้ควรถูกหยิบและเปลี่ยนผ่านกระบวนการตรวจสอบโค้ดและ / หรือเครื่องมืออัตโนมัติ

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

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

อย่าจับมาตรฐานการเข้ารหัสในเอกสาร จับมันในรหัสโดยมีกระบวนการอัตโนมัติซึ่งจะตรวจสอบมาตรฐานที่ถูกพบ

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

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

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

คนมองข้ามวัตถุประสงค์ที่แท้จริงของเอกสารมาตรฐานการเข้ารหัสซึ่งก็คือการระงับข้อพิพาท

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

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

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

(ดูเพิ่มเติมที่การปกครองแบบเผด็จการของโครงสร้าง )

เพราะการแสดงความคิดเห็นเป็นเรื่องโกหก

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

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

โปรแกรมเมอร์ใหม่ควรใช้เวลาดูรหัสไม่ใช่การใช้เวลาหลายวันอ่านเอกสารมาตรฐานหลายบท (ฉันต้องทำแบบนี้ถอนหายใจ)

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

การมีมาตรฐานรหัสเป็นสิ่งสำคัญ มีเอกสารที่กำหนดสิ่งที่พวกเขาไม่ใช่

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

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

เหตุใดฉันจึงไม่ควรเขียนมาตรฐานการเข้ารหัส

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

เขียนมันลง อย่างไรก็ตามฉันจะพยายามอธิบายเหตุผลของฉัน ...

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

อย่างไรก็ตามถ้อยคำของลุงบ๊อบไม่ได้ทำให้ฉันคิดว่าเขากำลังพูดถึงเรื่องนั้น

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

• ในบางสถานการณ์กฎหมายกำหนดมาตรฐานการเข้ารหัสเป็นลายลักษณ์อักษร
• ฉันอ่านเอกสารและฉันแน่ใจว่าฉันไม่ได้อยู่คนเดียว สมาชิกในทีมอาจเปลี่ยนแปลงได้เมื่อเวลาผ่านไปความรู้ไม่สามารถอยู่ใน codebase อายุ 5-10 ปีหรือในใจของสมาชิกในทีม องค์กรควรไล่คนที่ไม่ปฏิบัติตามแนวทางภายใน
• มาตรฐานการเข้ารหัสเมื่อได้รับการอนุมัติจะไม่เปลี่ยนแปลงบ่อยและหากคุณต้องการทราบเกี่ยวกับมัน หากมาตรฐานเปลี่ยนไปเอกสารของคุณ(เป็นรหัส) ล้าสมัยเพราะรหัสทั้งหมดของคุณไม่เป็นไปตามมาตรฐานใหม่ การจัดรูปแบบ / refactoring อาจจะช้า แต่คุณมักจะมีเขียนเผด็จการแนวทางที่จะปฏิบัติตาม
• การอ่านเอกสาร 5 หน้าดีกว่าการตรวจสอบ 10 / 20K LOC เพื่อคาดการณ์กฎ (ซึ่งคุณอาจเข้าใจผิด BTW) ไม่ต้องสงสัยเลยว่า
• เป็นเรื่องน่าขันที่ใครบางคนที่เขียนหนังสือหลายเล่มเกี่ยวกับหลักการออกแบบและสไตล์การเขียนโค้ดแนะนำว่าคุณไม่ควรเขียนแนวทางของคุณเองมันจะดีกว่าไหมถ้าเขาทิ้งตัวอย่างโค้ดไว้กับเรา? ไม่เพราะแนวทางที่เป็นลายลักษณ์อักษรไม่เพียง แต่บอกคุณว่าต้องทำอะไร แต่ยังมีอีกสองสิ่งที่รหัสขาด: สิ่งที่ไม่ควรทำและเหตุผลที่ต้องทำหรือไม่

"การเขียนโปรแกรมจัดระเบียบตนเองฟรี" ดีสำหรับนินจาอายุ 16 ปี แต่องค์กรมีข้อกำหนดอื่น ๆ :

• คุณภาพของรหัสจะต้องได้รับ (และกำหนดไว้) ในระดับ บริษัท ไม่ใช่สิ่งที่ทีมเดียวอาจตัดสินใจ พวกเขาอาจไม่มีทักษะในการตัดสินใจว่าจะดีกว่า (ตัวอย่างเช่นนักพัฒนาจำนวนเท่าไรมีทักษะที่จำเป็นทั้งหมดเพื่อทบทวน MISRA หรือแม้แต่เข้าใจกฎแต่ละข้อเท่านั้น)
• สมาชิกอาจถูกย้ายข้ามทีมต่าง ๆ : ถ้าทุกคนปฏิบัติตามมาตรฐานการเข้ารหัสเดียวกันการรวมนั้นราบรื่นและมีข้อผิดพลาดน้อยกว่า
• ถ้าทีมเป็นตัวการจัดระเบียบแล้วมาตรฐานจะมีวิวัฒนาการในช่วงเวลาที่สมาชิกในทีมเปลี่ยน - แล้วคุณจะมี codebase ขนาดใหญ่ที่ไม่เป็นไปตามปัจจุบันมาตรฐานได้รับการยอมรับ

หากคุณกำลังคิดเกี่ยวกับผู้คนก่อนกระบวนการผมขอแนะนำให้อ่านเกี่ยวกับ TPS เท่านั้น: มนุษย์เป็นส่วนสำคัญของการผลิตแบบลีน

แน่นอนว่าองค์กรขนาดเล็กที่มีเพียงหนึ่งทีมอาจปล่อยให้ทีมตัดสินใจว่าจะนำมาตรฐานมาใช้ แต่ต้องเขียนลงไป ที่นี่ใน Programmers.SE คุณอาจจะอ่านโพสต์โดยเอริค Lippert: ฉันคิดว่าเราทุกคนเห็นด้วยเขาเป็นนักพัฒนาที่มีประสบการณ์เมื่อเขาทำงานให้กับไมโครซอฟท์ที่เขาจะต้องเป็นไปตามหลักเกณฑ์การเขียนของพวกเขา (แม้ว่ากฎบางอย่างอาจจะไม่ถูกต้อง , ไม่ได้บังคับหรือไร้ประโยชน์ถึงเขา) แล้ว Jon Skeet ล่ะ? หลักเกณฑ์ของ Google ค่อนข้างเข้มงวด (และหลายคนไม่เห็นด้วยกับพวกเขา) แต่เขาต้องปฏิบัติตามแนวทางดังกล่าว พวกเขาดูหมิ่นหรือไม่? ไม่มีพวกเขาอาจจะทำงานเพื่อกำหนดและปรับปรุงแนวทางดังกล่าว บริษัท ไม่ได้ทำโดยหนึ่งในสมาชิก (หรือทีมใดทีมหนึ่ง) และแต่ละทีมไม่ได้เป็นเกาะ

ตัวอย่าง

• คุณตัดสินใจที่จะไม่ใช้มรดกหลายและการเรียนซ้อนกันใน C ++ เพราะคุณสมาชิกในทีมที่เกิดขึ้นจริงไม่เข้าใจมันได้ดี หลังจากนั้นบางคนที่ต้องการใช้การสืบทอดหลายครั้งต้องเรียกดู LOC ทั้งหมด 1M เพื่อดูว่ามีการใช้งานหรือไม่ มันไม่ดีเพราะถ้าการออกแบบไม่ได้มีการบันทึกไว้คุณต้องศึกษา codebase ทั้งหมดเพื่อทำความเข้าใจ และถึงแม้ว่าถ้ามันไม่ได้ใช้งานนั่นเป็นเพราะมันขัดกับมาตรฐานการเข้ารหัสหรืออนุญาต แต่ก็ไม่มีสถานการณ์ก่อนหน้านี้ที่การสืบทอดหลายแบบนั้นเหมาะสมหรือไม่
• ใน C # คุณมีวิธีการมากเกินไปเพื่อให้พารามิเตอร์เริ่มต้นเพราะฐานรหัสของคุณเริ่มต้นเมื่อพารามิเตอร์ทางเลือกไม่สามารถใช้ได้ใน C # จากนั้นคุณเปลี่ยนและคุณก็เริ่มใช้มัน (ทำการเปลี่ยนรหัสเก่าให้ใช้ทุกครั้งที่คุณต้องแก้ไขฟังก์ชั่นดังกล่าว) แม้ในภายหลังคุณตัดสินใจว่าพารามิเตอร์ทางเลือกไม่ดีและคุณเริ่มหลีกเลี่ยงการใช้พารามิเตอร์เหล่านั้น อะไรคือกฎรหัสของคุณบอกคุณ? มันไม่ดีเพราะวิวัฒนาการมาตรฐานแต่โค้ดเบสนั้นช้ากว่าที่จะวิวัฒนาการและถ้ามันเป็นเอกสารของคุณคุณก็มีปัญหา
• จอนย้ายจากทีม A ไปยังทีม B. จอนต้องเรียนรู้มาตรฐานใหม่ ในขณะที่การเรียนรู้เขาอาจจะแนะนำข้อบกพร่องที่ละเอียดยิ่งขึ้น (หรือหากโชคดีใช้เวลานานในการทำความเข้าใจโค้ดที่มีอยู่และทำให้การตรวจสอบโค้ดอีกต่อไป)
• ทีม A ย้ายไปยัง codebase ที่ทีม B เป็นเจ้าของก่อนหน้านี้มันมีมาตรฐานการเข้ารหัสที่แตกต่างกันโดยสิ้นเชิง เขียน? ปรับ? ผสม? พวกเขาทั้งหมดไม่ดีเท่ากัน

ลุงบ๊อบ

ปล่อยให้พวกมันมีวิวัฒนาการในช่วงการทำซ้ำสองสามครั้งแรก

ทรูจนกว่าคุณจะไม่ได้มีมาตรฐานและองค์กรของคุณได้รับมอบหมายงานที่คุณจะสร้างหนึ่ง

ให้พวกเขาเป็นทีมที่เฉพาะเจาะจงแทน บริษัท ที่เฉพาะเจาะจง

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

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

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

อย่าออกกฎหมายการออกแบบที่ดี (เช่นอย่าบอกให้คนอื่นไม่ใช้ goto)

จริงแนวทางต้องสั้นหรือไม่มีใครอ่านได้ อย่าทำซ้ำอย่างชัดเจน

ตรวจสอบให้แน่ใจว่าทุกคนรู้ว่ามาตรฐานนั้นเกี่ยวกับการสื่อสาร

ไม่เพียง แต่มาตรฐานที่ดีจะเกี่ยวกับคุณภาพเว้นแต่คุณต้องการมีรายละเอียดเพียงเล็กน้อยเท่านั้น

หลังจากการทำซ้ำสองสามครั้งแรกให้ทีมร่วมกันตัดสินใจ

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

สามบันทึก:

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

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

เหตุใดฉันจึงไม่ควรเขียนมาตรฐานการเข้ารหัส

มีหลายเหตุผลสำหรับสิ่งนี้ นี่คือข้อควรพิจารณาบางอย่าง:

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

2. เมื่อโครงการได้รับการ defunded / shelved / etc จากนั้นคนไม่กี่คนที่ยังคงไม่สามารถปฏิบัติตามมาตรฐานได้ (หรืออาจยังไม่ได้อ่าน) มาตรฐาน สิ่งต่อไปที่คุณรู้ว่าความพยายามในการ "รักษารหัสให้สะอาด" นั้นก็เป็นการสูญเปล่าไปแล้ว

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

คุณควรอ่าน # 6:

หลังจากการทำซ้ำสองสามครั้งแรกให้ทีมร่วมกันตัดสินใจ

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

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

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

ประการแรกเท่าที่ฉันรู้ลุงบ๊อบเป็นคนชวาสิ่งนี้สำคัญมากสำหรับการทำความเข้าใจสิ่งที่เขาพูด

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

ทั้ง Java และ C # พร้อมด้วยภาษาที่ทันสมัยส่วนใหญ่ได้รับการกำหนดเพื่อให้มีกับดัก "ง่าย" น้อยสำหรับโปรแกรมเมอร์ที่จะตกอยู่ใน

อย่างไรก็ตามเมื่อฉันเริ่มเขียนโปรแกรมฉันใช้ C (และ C ++ ภายหลัง) ใน C คุณสามารถเขียนโค้ดเช่น

if (a = 3);
{
   /* spend a long time debugging this */
}

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

if (3 = a)
{
   /* looks odd, but makes sense */
}

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

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

มีเหตุผลที่ฉันไม่เคยชอบ JScript และคิดว่า TypeScript เป็นสิ่งที่ดีที่สุดสำหรับการพัฒนาเว็บไซต์เป็นเวลาหลายปี ฉันคาดหวังว่านักพัฒนา Web UI ยังต้องการมาตรฐานการเข้ารหัสเนื่องจากข้อบกพร่องในการออกแบบ HTML / CSS / JScript เป็นต้น

มีแหล่งที่มาเป็นมาตรฐานการเข้ารหัสเอกสารด้วยตนเองหมายถึงสองสิ่ง

1. ผู้คนต้องปรึกษาฐานของรหัสและตรวจสอบเพื่อที่จะเป็นผู้มีความเชี่ยวชาญ นี่เป็นสิ่งสำคัญอย่างยิ่ง แนวทางการอ่านโค้ดเป็นการเสียเวลาเมื่อเทียบกับการดำน้ำในฐานรหัส
2. มันยอมรับว่าความแตกต่างเล็กน้อยนั้นไม่สำคัญ สิ่งสำคัญคือการเห็นด้วยและเข้าใจหลักการพื้นฐาน การรักษาสไตล์ที่สอดคล้องกันไม่ได้ดำเนินการตามที่ lartart l'art ไม่อนุญาตให้ผู้ทำจิงเกอร์ที่ไม่มีความคิดสร้างสรรค์สร้างความรำคาญและกวนใจผู้อื่น มันเกี่ยวกับการอำนวยความสะดวกในการสื่อสารผ่านรหัสในทีม

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

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

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

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

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

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

เกี่ยวข้องอย่างยิ่ง: วิวัฒนาการในมาตรฐานการเข้ารหัสคุณจะจัดการกับมันอย่างไร

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

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

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

ผมคิดว่าการโพสต์มากมายที่นี่มีความสับสนมาตรฐานการเข้ารหัสกับคู่มือสไตล์

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

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

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

บางสิ่งที่แพร่หลายและมีความสำคัญเช่นไม่ใช้ข้อยกเว้นหรือไม่ได้ใช้newในระบบฝังตัวบางอย่างไม่สามารถทิ้งไว้ให้เป็นความรู้ทางวัฒนธรรมทั่วไปได้เนื่องจาก "ข้อมูลเป็นวัฒนธรรม (เท่านั้น)" ขัดแย้งกับหลักการพื้นฐานของมาตรฐานการผลิตเช่น ISO-9000 ผู้พัฒนาระบบฝังตัวเหล่านี้กำลังใช้งาน (เช่นสำหรับแอปพลิเคชันยานยนต์) สิ่งสำคัญเหล่านี้จะต้องมีการลงนามในเอกสารและยื่นแบบเป็นทางการ

แต่ที่นำไปใช้กับการเข้ารหัสไม่ได้ที่จะสไตล์

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

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

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