ทีมของฉันควรใช้มาตรฐานการเข้ารหัสที่ได้รับการยอมรับเป็นพื้นฐานของตัวเองหรือไม่?

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

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

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

นี่เป็นเรื่องธรรมดาไหม คุณเชื่อว่านี่เป็นความคิดที่ดีหรือไม่? ถ้าเป็นเช่นนั้นสิ่งที่จะเป็นมาตรฐานการเข้ารหัส 'พื้นฐาน' ที่เหมาะสม (อย่าบอกฉันว่าอะไรดีที่สุดฉันไม่ต้องการเริ่มต้นความขัดแย้งทางศาสนาที่นี่เพียงแค่ชี้ให้เห็นว่าอะไรจะครอบคลุมหรือ 'เป็นกลาง' พอที่จะสร้าง .)

หมายเหตุ:

• เราคาดว่าจะทำงานกับ C, C ++, OpenCL, CUDA, Python
• เราเป็นทีมงานของ 4 คน + ผู้จัดการคาดว่าจะเติบโตประมาณ 5-6 ภายในหนึ่งปี
• ใน บริษัท ของเราทีมเกือบทั้งหมดเป็นอิสระและมักจะไม่โต้ตอบเลย (ไม่ใช่แม้กระทั่งโดยใช้รหัสของกันและกัน - งานอยู่ในโครงการที่แตกต่างกันโดยสิ้นเชิง); ดังนั้น - ไม่มีข้อควรพิจารณาทั่วทั้ง บริษัท
• เกี่ยวกับเครื่องมือในขณะนี้สิ่งที่เรารู้คือเรากำลังจะใช้Eclipseดังนั้นฟอร์แมตโค้ดของมันจะเป็นเครื่องมืออย่างน้อยหนึ่งตัว Ctrl + Shift + F เป็นเพื่อนของฉันมานานแล้ว
• เมื่อผมเขียน Java ผมได้นำมาใช้ในการปฏิบัติของการยึดมั่นอย่างเคร่งครัดในฐานะที่เป็นไปได้กับโบลชมีผลบังคับใช้ Java ตอนนี้นั่นไม่ใช่มาตรฐานการเข้ารหัส แต่คุณสามารถเรียกอิฐอิฐซีเมนต์และปูนเพื่อขอรหัสมาตรฐานได้ ฉันคิดว่าอาจรวมถึงสิ่งที่เป็นส่วนหนึ่งของ 'มิกซ์' (คิดว่าเราไม่ได้ทำจาวา)
• ผมหมายถึงมาตรฐานการเข้ารหัสในความหมายที่กว้างขึ้นของคำเช่นการนำข้อเสนอแนะทำในคำตอบของคำถามนี้ P.SE
• ฉันพบรายการเอกสารมาตรฐานการเข้ารหัส C ++ ขนาดใหญ่แล้ว บางทีฉันควรจะทำอย่างนั้นพื้นฐานของเรา
• (*) นั่นไม่จริง แต่ฉันไม่ต้องการที่จะทำให้คำถามนี้ซับซ้อนมากเกินไป

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

แจ่มแจ้งคำตอบคือใช่

มาตรฐานที่มาจากภายนอกนั้นเหนือกว่าสิ่งใด ดูคำตอบใน " https://softwareengineering.stackexchange.com/q/84203/53019 " เพื่อดูข้อดีบางประการของการมีมาตรฐาน ความสอดคล้องและการมีพื้นฐานการเปลี่ยนแปลงมีความสำคัญจากมุมมองของคุณ

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

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

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

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

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

ฉันเริ่มต้นด้วยหลาม Python มีแนวทางในการเขียนโปรแกรมซึ่งโปรแกรมเมอร์ของ Python เกือบทุกตัวมีดังนี้ พวกเขาเป็นส่วนหนึ่งของเอกสารอย่างเป็นทางการเรียกว่าPEP8

C / C ++ นั้นยุ่งมากด้วยเหตุผลทางประวัติศาสตร์ แต่เนื่องจาก python ไม่ได้เป็นเช่นนั้นฉันขอแนะนำให้คุณทำตามแบบแผนการตั้งชื่อของ python ใน C / C ++ เช่นกันเพื่อความมั่นคง

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

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

มาตรฐานการเข้ารหัสคือชุดของกฎที่กำหนดกลไกภาษาที่คุณได้รับอนุญาตให้ใช้ซึ่งเป็นกฎที่คุณไม่ได้รับอนุญาตให้ใช้และวิธีการใช้ กล่าวอีกนัยหนึ่งคุณกำหนดเซตย่อยของภาษาที่ใช้และ / หรือเซ็ตเซ็ตหากมาตรฐานการเข้ารหัสระบุแอดเดรสส่วนขยายที่ไม่ได้มาตรฐาน

มาตรฐานรูปแบบการเข้ารหัสนั้นเกี่ยวข้องกับปัญหาด้านเครื่องสำอางเท่านั้น: สถานที่จัดฟันและช่องว่าง, วิธีระบุชื่อ, วิธีแสดงความคิดเห็นเป็นต้น

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

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

มาตรฐานจากCERTนั้นเป็นที่รู้จักกันดีและค่อนข้างมีอคติต่อการเขียนโปรแกรมเดสก์ท็อปและความปลอดภัยของซอฟต์แวร์ (มากกว่าความปลอดภัย) CERT มีมาตรฐานสำหรับ C, C ++, Java และ Perl และมาตรฐานไม่มีค่าใช้จ่าย

ฉันจะเริ่มต้นด้วยการดู MISRA และ CERT แทนที่จะเป็นมาตรฐานโรงรถแบบสุ่มที่พบในเว็บ

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

หากคุณไม่แน่ใจว่าจะใช้มาตรฐานการเข้ารหัสใดมีตัวเลือกแรกที่เหมาะสมอย่างชัดเจน ในลำดับ
ใด ๆ: 1. IDE ใดก็ตามที่มาตรฐานของคุณรองรับอยู่แล้ว อาจกำหนดค่าได้
2. มาตรฐานใดที่ใช้ / แนะนำโดยผู้แต่งคอมไพเลอร์ของคุณ
3. ผู้สร้างเฟรมเวิร์กหลักของคุณจะใช้หรือแนะนำมาตรฐานใด (หากมี)
4. มาตรฐานใดที่ใช้ / แนะนำโดยผู้แต่ง / ผู้ออกแบบภาษาการเขียนโปรแกรมของคุณ
5. มาตรฐานใดที่ใช้ / แนะนำโดย บริษัท ขนาดใหญ่มาก

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

มาตรฐานมักจะช่วยให้การสื่อสารและการบำรุงรักษา ในความคิดของฉันมันควรมีการให้และรับโดยเฉพาะอย่างยิ่งในทีมเล็ก ๆ และควรพัฒนา แนวทางการเรียกพวกเขาอาจช่วย :-)

ดูแนวทางของ Googleเพื่อหาแรงบันดาลใจ

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

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

ฉันพบว่ามาตรฐานเช่นตำแหน่งไฟล์และชื่อนั้นมีประโยชน์มากกว่า 1 ซึ่งโค้ดเหล่านั้น (หลังจากทั้งหมดโค้ดมาในรูปทรงและขนาดทั้งหมดและคุณยังต้องอ่าน) ในขณะที่ไม่ทราบว่า readme.txt อยู่ใน / bin / doc / debug / release / เอกสารเป็นความเจ็บปวดที่แท้จริง (เช่นเส้นทางเส็งเคร็ง แต่นั่นเป็นอีกเรื่อง)

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

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