เป็นความคิดที่ดีหรือไม่ที่จะเรียกใช้ตัวจัดรูปแบบรหัสเป็นระยะในที่เก็บ?

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

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

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

ฟังดูดี แต่ฉันต้องการให้คนที่รับผิดชอบในการยอมรับการเปลี่ยนแปลงรหัสไม่ใช่บอท

นอกจากนี้คุณต้องแน่ใจว่าการเปลี่ยนแปลงเหล่านั้นไม่ทำลายอะไรเลย ตัวอย่างเช่นเรามีกฎที่สั่งซื้อคุณสมบัติและวิธีการตามตัวอักษร สิ่งนี้สามารถส่งผลกระทบต่อฟังก์ชันการทำงานตัวอย่างเช่นลำดับของข้อมูลและวิธีการในไฟล์ WSDL ของสัญญา WCF

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

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

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

ฉันมักจะเชื่อว่ามันเป็นความคิดที่ดี (ในการรันตัวจัดรูปแบบโค้ดโดยอัตโนมัติ) แต่นั่นเป็นเพียงความคิดเห็นของฉัน

ฉันจะไม่เรียกใช้มันเป็นระยะ ๆ แต่ถ้าเป็นไปได้ก่อนที่จะส่งการควบคุมเวอร์ชัน

เมื่อใช้คอมไพล์แล้วการทำเบ็ดล่วงหน้าที่ทำนั้นจะเป็นประโยชน์ ในโครงการ C หรือ C ++ หลายโครงการที่สร้างด้วยMakefileบางตัวฉันกำลังเพิ่มindentเป้าหมาย (ซึ่งเรียกใช้ตัวจัดรูปแบบโค้ดที่เหมาะสมเช่นindentหรือastyle) และคาดว่าผู้มีส่วนร่วมจะทำงานmake indentเป็นประจำ BTW คุณสามารถเพิ่มmakeกฎบางอย่างเพื่อให้แน่ใจว่ามีการติดตั้ง git hooks (หรือเพื่อติดตั้ง)

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

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

BTW ชุมชนที่แตกต่างและภาษาการเขียนโปรแกรมที่แตกต่างกันมีมุมมองที่แตกต่างกันในการจัดรูปแบบโค้ด ตัวอย่างเช่นGoมีสไตล์การจัดรูปแบบโค้ดเพียงอย่างเดียว แต่ C หรือ C ++ มีรูปแบบมากมาย

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

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

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

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

ในหลอดเลือดดำเดียวกับคำแนะนำของ @ BasileStarynkevitch เราใช้ hooks การรับหลังการรับ git ของเซิร์ฟเวอร์เพื่อส่ง "อีเมลคำแนะนำ" เกี่ยวกับรูปแบบโค้ด

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

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

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

ดังที่ @DocBrown พูดตัวเลือกอื่นคือบังคับใช้รูปแบบโค้ดภายใน IDE ของคุณ เราใช้CodeMaidกับ Visual Studio เพื่อแก้ไขข้อผิดพลาดสไตล์ทั่วไปมากมาย มันจะทำงานเมื่อบันทึกไฟล์รหัสซึ่งหมายความว่าโค้ดที่ไม่ดีไม่ควรทำให้เป็น repo ... ในทางทฤษฎี :-)

ใช่ฉันคิดว่ามันเป็นความคิดที่ไม่ดี อย่าเข้าใจฉันผิดเหตุผลที่ทำให้มันฟังดูดี แต่ผลที่ได้ยังน่ากลัวอยู่

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

ฉันไม่ต้องการทดสอบตอนนี้ที่ทำงาน แต่คุณควรลองด้วยตัวเอง

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

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

แต่คุณสามารถใส่มันลงในงานสร้างทุกคืนหรืองานสร้างรายสัปดาห์

แต่แม้กระทั่งทุกคืนอาจเป็นความคิดที่ไม่ดี

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

มิฉะนั้นให้เรียกใช้ปีละ 1-2 ครั้งในช่วงเทศกาลวันหยุดเมื่อมีข้อขัดแย้งที่เกิดขึ้นจะไม่เกิดขึ้น

แต่โซลูชันอาจขึ้นอยู่กับลำดับความสำคัญของคุณสำหรับรูปแบบโค้ด

ฉันคิดว่าการสร้างสคริปต์การตั้งค่าที่สร้างที่เก็บ git โดยอัตโนมัติและตั้งค่า hooks สำหรับโครงการจะดีกว่า

หรือคุณอาจรวมสคริปต์การตั้งค่า hook ไว้ในโฟลเดอร์สำหรับ devs ของคุณภายในโครงการและเพียงตรวจสอบมันเข้าไปในคอมไพล์เอง

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

มันเป็นความคิดที่น่ากลัว

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

หากคุณต้องการทำสิ่งนี้เป็นประจำนั่นเป็นเรื่องที่น่ากลัวมาก

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

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

คุณไม่ได้พูดถึง VCS ที่คุณใช้ แต่ขึ้นอยู่กับว่าอีกตัวเลือกหนึ่งคือการขอใช้ฝั่งเซิร์ฟเวอร์ VCS อย่างคอมไพล์สนับสนุนสิ่งนั้น คุณสามารถติดตั้ง hook ด้านเซิร์ฟเวอร์ที่รันตัวจัดรูปแบบบนเวอร์ชันที่ถูกพุชแล้วเปรียบเทียบไฟล์ที่จัดรูปแบบกับเวอร์ชันที่จะถูกพุช หากพวกเขาต่างกันนักพัฒนาไม่ได้ใช้การจัดรูปแบบที่ถูกต้องและเซิร์ฟเวอร์อาจปฏิเสธการผลักดัน สิ่งนี้จะบังคับให้ devs ของคุณส่งเฉพาะโค้ดที่มีการจัดรูปแบบที่ต้องการเท่านั้นซึ่งจะเป็นการกระตุ้นให้พวกเขาเขียนโค้ดที่สะอาดตั้งแต่ต้นมันจะทำให้ devs ที่รับผิดชอบในการทดสอบโค้ดที่จัดรูปแบบอย่างถูกต้องและบรรเทา devs ของคุณเอง ตะขอ.

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

ความคิดนี้คล้ายกับคำตอบอื่น ๆ แต่ฉันไม่สามารถแสดงความคิดเห็นคำแนะนำของฉัน

ทางเลือกหนึ่งคือการตั้งค่านามแฝง (หรือตะขอหรืออะไรก็ได้) ไปยังฟังก์ชั่นการกระทำที่ใช้ฟอร์แมตโค้ดบนโค้ดที่ต้องถูกยืนยันก่อนที่จะถูกคอมมิต

อาจมีผลลัพธ์ 2 (หรือมากกว่า):

1) แสดงการเปลี่ยนแปลงที่เสนอให้กับผู้ใช้และขอการอนุมัติของพวกเขาเพื่อนำไปใช้และยอมรับการเปลี่ยนแปลง

2) ละเว้นการเปลี่ยนแปลงที่เสนอและส่งรหัสต้นฉบับ

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

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

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

ส่วนที่ดีคือมันเป็นส่วนหนึ่งของโครงการดังนั้นนักพัฒนาทุกคนจะได้รับมันสำหรับโครงการของพวกเขา

การรวมโบนัสเพิ่มเติมจะง่ายขึ้นอย่างมากเนื่องจากสิ่งต่างๆจะไม่กระโดดไปมา

การตรวจสอบรหัสจะป้องกันการกระทำผิดพลาดใด ๆ

อีกที่หนึ่งที่ฉันอยากทำคือมีส่วนของสิ่งก่อสร้าง ในกรณีของฉันฉันมีมันที่ maven builds จะทำการฟอร์แมต XML และล้างไฟล์ pom และฟอร์แมตโค้ดใหม่

ด้วยวิธีนี้เมื่อนักพัฒนาซอฟต์แวร์พร้อมที่จะผลักดันทุกคนจะได้รับการทำความสะอาดสำหรับคำขอการดึง