มีวิธีในการสนับสนุนรูปแบบการเข้ารหัสที่แตกต่างกันในทีมพัฒนาหรือไม่

ปัญหา: นักพัฒนาสองคน => สามความคิดเห็นต่อการเยื้อง, การจัดฟันในบรรทัดใหม่หรือไม่ ฯลฯ

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

ดังนั้นคำถามคือ: มีวิธีให้โปรแกรมเมอร์แต่ละคนใช้สไตล์ของตนเอง แต่มีฐานรหัสทั่วไปภายในพื้นที่เก็บข้อมูลหรือไม่ ฉันคิดว่าบาง git / svn / ปลั๊กอินใด ๆ ซึ่งการเปลี่ยนแปลงระหว่างสไตล์ส่วนตัวและทั่วไปในการชำระเงินและกระทำ ดูเหมือนว่าฉันว่าส่วนที่ยุ่งยากในวิธีนี้คือการสนับสนุนความแตกต่างที่ถูกต้องระหว่างเวอร์ชันของไฟล์

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

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

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

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

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

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

คำตอบสั้น ๆ คือไม่

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

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

1. รายการเลย์เอาต์เช่นการแท็บการเยื้องการใช้ {, (,
2. ชื่อตัวแปรและฟังก์ชันเช่น CamelCase, สัญลักษณ์ของฮังการี
3. การจัดการข้อยกเว้นวิธี / เวลา / สถานที่ที่จะดำเนินการ
4. รหัสความคิดเห็น คุณอ้างอิงเอกสารการออกแบบหมายเลขข้อผิดพลาดและอื่น ๆ เสมอ

เอกสารมาตรฐานช่วยให้มั่นใจได้ว่ารหัสนั้นง่ายต่อการอ่านบำรุงรักษาและสอดคล้องในอนุสัญญา

นี่เป็นสิ่งที่ประเมินค่าไม่ได้เมื่อตรวจสอบรหัสก่อนการตรวจสอบการดีบักรหัสของบุคคลอื่นหรือแก้ไขรหัสหลายปีหลังจากผู้พัฒนาดั้งเดิมออกจาก บริษัท

โดยปกติเมื่อสร้างเอกสารมาตรฐานการเข้ารหัสฉันตรวจสอบมาตรฐานอุตสาหกรรมสำหรับภาษาที่ฉันใช้ (C, C #, SQL) ให้ใช้มาตรฐานที่เหมาะสมที่สุดเวียนไปที่นักพัฒนาอาวุโส / ผู้มีอิทธิพลมากที่สุดเพื่อแสดงความคิดเห็นรวมความคิดเห็นตามความเหมาะสม ปล่อยเอกสาร

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

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

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

นี่คือการอภิปรายที่คล้ายกันในกองมากเกิน

การฟอร์แมตโค้ดอัตโนมัติแบบทางเดียวอาจเป็นวิธีแก้ปัญหาที่ใช้การได้หากคุณ:

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

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

อย่างที่คุณสามารถ มันคือทั้งหมดที่เกี่ยวกับการไม่เหงื่อออกของเล็ก ๆ น้อย ๆ

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

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

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