คู่มือสไตล์สำหรับ C ++ [ปิด]


29

ตอนนี้ฉันกำลังใช้คู่มือสไตล์ C ++ ของ Googleในรหัส C ++ ของฉันและฉันก็ค่อนข้างพอใจกับมัน

เมื่อเร็ว ๆ นี้ฉันได้รับแจ้งว่าคู่มือนี้ไม่ดีมาก: Google ใช้งานภายใน (ฉันรู้ว่า) ล้าสมัยและส่งเสริมการปฏิบัติที่ไม่ดีบางอย่าง ดังนั้นฉันต้องการใช้รูปแบบการเข้ารหัสอื่น

มีคำแนะนำสไตล์ C ++ ที่ดีและใช้งานอย่างเป็นธรรมอะไรบ้าง? ฉันเขียนโค้ดสำหรับทั้ง gcc และ Visual Studio และฉันใช้คุณสมบัติ C ++ 11 มากมาย

สิ่งที่ฉันชอบมากเกี่ยวกับคู่มือสไตล์ Google C ++คือการเยื้องช่องว่างและการตั้งชื่อ (โดยเฉพาะการตั้งชื่อคลาสทุกประเภท - รวมถึง typedefs, นามแฝงประเภทและนามแฝงเทมเพลต - ด้วยอักษรตัวใหญ่ตัวแรก)

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


1
คุณสามารถใช้สไตล์ที่คุณชอบได้ตลอดเวลาจากนั้นจึงจัดรูปแบบใหม่ตามสไตล์ที่ต้องการเมื่อคุณต้องการแชร์ นี่คือตัวจัดรูปแบบลักษณะที่ทำให้astyle.sourceforge.net
Reactgular

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

@ andy256 ไม่สามารถพูดได้ดีกว่านี้เอง
bolov

7
ใครบอกว่าสไตล์ของ Google ไม่ดีและทำไมความเห็นของพวกเขาถึงมีความสำคัญกับคุณ
ซ้ำ

@MathewFoscarini มีการสนทนาเมื่อไม่นานมานี้ที่นี่ถึงแม้ว่ามันจะไม่ลึกเกินไป: chat.stackoverflow.com/rooms/10/conversation/ ...... (แต่จากนั้นการผ่านมันในเชิงลึกก็เหมือนกับการผ่าน FQA )
Cubbi

คำตอบ:


15

คุณสามารถใช้แนวทางจากหนังสือเล่มนี้สำหรับการใช้งานทั่วไป:

http://www.amazon.com/Coding-Standards-Rules-Guidelines-Practices/dp/0321113586

จาก Herb Sutter และ Andrei Alexandrescu มันไม่ได้คำนึงถึง C ++ 11 แต่ฉันคิดว่าจะมีฉบับใหม่

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


22

c ++ แนวทางหลักเป็นชุดของความพยายามและความจริงแนวทางหลักเกณฑ์และแนวทางปฏิบัติที่ดีที่สุดเกี่ยวกับการเขียนโปรแกรมใน C ++ คุณสามารถค้นหาได้ที่นี่: https://github.com/isocpp/CppCoreGuidelines

พวกเขาจะเขียนโดยหมู่คนอื่น ๆBjarne Stroustrup และSutter สมุนไพร


1
แน่นอนดีกว่าวิธีการแก้ปัญหาของ Nikko
WHN

8

การวิพากษ์วิจารณ์แนวทางสไตล์ C ++ ของ Google (และฉันเห็นด้วยบางข้อก็เป็นธรรม) ไม่ได้เกี่ยวกับแผนการตั้งชื่อหรือรูปแบบการเยื้องของ Google แต่เกี่ยวกับกฎและนโยบายอื่น ๆ การเยื้อง / การจัดรูปแบบและการตั้งชื่อการประชุมเป็นทั้งเรื่องของการลิ้มรสและเป็นพื้นดินที่อุดมสมบูรณ์สำหรับสงครามทางศาสนาที่ไม่มีที่สิ้นสุดโปรแกรมเมอร์ แต่ใน C ++ ซึ่งแตกต่างจากการพูดว่า C # ไม่มีมาตรฐานสากล สำหรับโครงการใหม่ให้เลือกแบบแผนการตั้งชื่อและรูปแบบการเยื้องที่คุณชอบและใช้อย่างสม่ำเสมอ สำหรับโครงการที่มีอยู่ให้ใช้หลักการที่มีอยู่แล้ว กฎข้อที่ 0 ในมาตรฐานการเข้ารหัส C ++คือ "อย่าทำสิ่งเล็ก ๆ น้อย ๆ " ที่พวกเขายืนยันว่าการตั้งชื่อการประชุมและรูปแบบการเยื้องนั้นไม่สำคัญตราบเท่าที่คุณ '

ผู้สนับสนุนการผลิตใหญ่สำหรับฉันได้รับอัตโนมัติเยื้อง / การจัดรูปแบบการใช้เสียงดังกราวรูปแบบ เมื่อคุณตัดสินจากกฎการเยื้องและการจัดรูปแบบแล้วฉันขอแนะนำให้ตั้งค่าไฟล์การจัดรูปแบบ .clang ที่กำหนดเองแล้วไม่ต้องกังวลอีก :-)

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


6

ตามที่ @ user113896 เขียนไว้ก่อนหน้านี้ Bjarne Strostrup ให้คำแนะนำเรื่องสไตล์กับเรามากมาย หนึ่งในความสำเร็จของเขาดีเป็นJSF-C ++ หนังสือ ระวังไม่ใช่สำหรับ c ++ ปกติมากกว่าสำหรับการใช้งานแบบฝังตัว แต่มันแสดงให้เห็นว่าควรทำสิ่งใดให้ชัดเจนและใช้งานได้ แน่นอน - คุณไม่จำเป็นต้องคำนึงถึงทุกสิ่ง - เป็นแนวทางไม่ใช่คำสั่งจอง :)


2

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

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.