การกำหนดรูปแบบรหัสเดียวกันสำหรับนักพัฒนาทั้งหมดเป็นความคิดที่ดีหรือไม่

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

ดังนั้นฉันเชื่อว่าข้อได้เปรียบนั้นชัดเจน (readability => การเพิ่มผลผลิต) แต่เป็นความคิดที่ดีที่จะกำหนดสิ่งนี้หรือไม่? และถ้าไม่ทำไม?

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

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

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

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

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

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

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

นักพัฒนาซอฟต์แวร์หลายคนเข้าร่วมสงคราม evangelical ......

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

ใช่นั่นเป็นเรื่องดีที่จะมีรูปแบบรหัสหนึ่งรูปแบบสำหรับนักพัฒนาทั้งหมด

ออกแบบรูปแบบสไตล์ของรหัสและนำเข้าที่นักพัฒนาคราสทั้งหมด

สิ่งนี้จะช่วยได้เมื่อเราใช้mergingรหัสในระบบ 'การควบคุมเวอร์ชัน'

คุณกำลังพยายามจะได้อะไรคุณจะพยายามบังคับทางทวารหนักอย่างไร (และในระดับรายละเอียด "กฎ" ของคุณจะถูกกำหนดไว้) คุณจะพยายามบังคับใช้กับรหัสที่เขียนด้วยภาษาต่างๆ คุณจะพยายามบังคับใช้มันย้อนหลังกับรหัสที่มีอยู่?

1. การมองและใช้โค้ดร่วมกันสามารถช่วยให้โค้ดอ่านง่ายขึ้น แต่ก็สามารถทำให้สิ่งต่าง ๆ แย่ลงได้ถ้ามันเป็นรูปลักษณ์และความรู้สึกที่ผิด _hUngarian_lpfstr สัญกรณ์เป็นตัวอย่างสำคัญ :)
2. ฉันเห็น "มาตรฐานรหัส" บังคับใช้จำนวนช่องว่างของช่องว่างระหว่างในบล็อกความคิดเห็นการเรียงลำดับตัวอักษรของชื่อเมธอดและเรื่องไร้สาระอื่น ๆ อย่าทำอย่างนั้น
3. ภาษาที่ต่างกันมีมาตรฐานที่แตกต่างกันซึ่งผู้คนคุ้นเคยกับการใช้งานของพวกเขา บางคนถึงกับมอบอำนาจมาตรฐานเหล่านี้ (คิดว่า Python, Cobol, Visual Studio กำหนดข้อตกลงการจัดรูปแบบ C ++ โดยอัตโนมัติขณะที่ Java ใช้รูปแบบ C ตามการประชุม ฯลฯ )
4. ไม่เคยเปลี่ยนรหัสที่มีอยู่เพื่อประโยชน์ในการเปลี่ยนแปลงคุณเพียงแนะนำปัญหาใหม่ด้วยวิธีนี้ และนั่นหมายถึงส่วนของรหัสเช่นเดียวกับไฟล์ต้นฉบับทั้งหมด ดังนั้นอย่าไปฟอร์แมตโค้ดที่มีอยู่เมื่อมีคนเปลี่ยนบรรทัดเดียวในไฟล์ 1,000 บรรทัด
5. โปรแกรมเมอร์ที่มีประสบการณ์สามารถทำงานได้อย่างมีประสิทธิผลมากขึ้นหากพวกเขาไม่ต้องคิดครึ่งเวลาว่าสิ่งที่พวกเขาเขียนจะ“ ดูถูกต้อง” ไปยังระบบอนุมัติอัตโนมัติหรือผู้ตรวจสอบ พวกเขายังคงมีนิสัยในการเขียนโค้ดที่เรียบง่ายเพราะนั่นเป็นสิ่งที่ใช้ได้แม้ว่าจะมีความแตกต่างเล็กน้อยระหว่างสไตล์ธรรมชาติของพวกเขา

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

ใช่สม่ำเสมอเป็นความคิดที่ดีสำหรับเหตุผลที่คนอื่น ๆได้กล่าวถึง

ฉันแค่ต้องการเพิ่มจุดสองสามอย่างที่ไม่ได้ใช้ในที่อื่น:

• Oracle ได้เผยแพร่ชุดของการประชุมสำหรับ Java ซึ่งเป็นมาตรฐานโดยพฤตินัย
  • การใช้สิ่งเหล่านี้จะช่วยให้คุณหลีกเลี่ยงข้อโต้แย้งเกี่ยวกับสไตล์ที่ต้องติดตาม
  • ห้องสมุดสาธารณะจำนวนมากและโครงการโอเพ่นซอร์สมักจะใช้การประชุมเหล่านี้ดังนั้นเมื่อคุณจำเป็นต้องดูที่การจัดรูปแบบควรจะคุ้นเคย
  • ตัวจัดรูปแบบ Eclipse มีกฎในตัวเพื่อให้ตรงกับอนุสัญญาเหล่านี้ซึ่งควรช่วยด้วย
• คุณอาจต้องการสร้างเบ็ดในการตั้งค่าการควบคุมแหล่งที่มาของคุณเพื่อให้รหัสได้รับการจัดรูปแบบอัตโนมัติก่อนที่จะเข้าสู่สาขาหลัก
  • คุณสามารถหลีกเลี่ยงการต่อสู้กับโปรแกรมเมอร์ที่ดื้อรั้นโดยเฉพาะที่ปฏิเสธที่จะทำตามมาตรฐาน พวกเขายังสามารถใช้การจัดรูปแบบของตัวเองในขณะที่ทำงานซึ่งจะได้มาตรฐานในภายหลัง!
  • หากคุณใช้การตั้งค่าการจัดรูปแบบที่กำหนดเอง (เช่นผู้คนจำนวนมากเพิกเฉยต่อข้อตกลง "สูงสุด 80 ตัวอักษรต่อบรรทัด") คุณต้องทำการเปลี่ยนแปลงในที่เดียวเท่านั้น

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

(ตัวอย่างของการตัดสินใจของเรา: ความกว้าง 72 ตัวอักษรเล็กเกินไป แต่ดีกว่า 120 ตัวดีกว่าการใช้ _ALLCAPS สำหรับรอบชิงชนะเลิศคงที่การบังคับให้ออกจากระบบครั้งเดียวเป็นความคิดที่ดี)

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

(การลบกลิ่นรหัสมีความสำคัญมากกว่าการจัดรูปแบบที่สอดคล้องกันซึ่งเป็นข้อดีของเครื่องมืออัตโนมัติ)

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

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

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

การตั้งค่าส่วนบุคคลเป็นเพียงแค่นั้นและไม่ค่อยปรับปรุงการผลิต: https://stackoverflow.com/questions/249432/whats-the-reasoning-behind-the-different-brace-forms

ถ้าเป็นเช่นนั้นให้ข้ามและทำสิ่งนั้นให้สำเร็จ

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

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

เกี่ยวกับ "readability => Productivity" โครงสร้างรหัส (เช่นคลาสความรับผิดชอบและฟังก์ชั่นเดียว) จะซื้อคุณได้เร็วกว่าการจัดรูปแบบโค้ด การจัดรูปแบบโค้ดอาจช่วยได้ แต่จิตใจที่แตกต่างกันแยกคำสั่งต่างกัน - ไม่ใช่ทุกคนที่จะ "มีประสิทธิผลมากขึ้น" ฉันต้องการดับเบิลโครงสร้างของรหัสผ่านการจัดรูปแบบเพราะนั่นคือสิ่งที่จะนำคุณไปสู่การตรวจสอบโค้ดและให้ทีมคิดเกี่ยวกับวิธีการทำงานของโปรแกรมไม่ใช่ลักษณะของลูปเดี่ยว

ฉันไม่ใช่แฟนตัวยงของ Domain Driven Design แต่เป็นรุ่นล่าสุดหนึ่งที่มีแนวคิดที่กำหนดไว้เป็นอย่างดีเกี่ยวกับวิธีการจัดโครงสร้างโค้ดและการจัดรูปแบบโค้ดที่ไหลออกมาจากโปรแกรมที่ออกแบบโครงสร้างด้วย Domain Driven Design อีกครั้ง ... ฉันไม่ชอบ DDD แต่มันก็เป็นตัวอย่างที่ดีเพราะมันชัดเจนมาก

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

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

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

ที่ถูกกล่าวว่ากฎที่ยากกว่าของ "การปฏิบัติตามข้อตกลงรหัสที่มีอยู่แล้วในไฟล์ / โครงการ" เป็นสิ่งที่ดี

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

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

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

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

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

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

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

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

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

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

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

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

มันเหมือนกับการขับรถของคนอื่น ...

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

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

+1 กับผลประโยชน์ทั้งหมดที่กล่าวถึงแล้ว แต่ ...

การบังคับใช้อัตโนมัติมาพร้อมกับค่าใช้จ่ายที่ต้องพิจารณา:

-1 กับข้อเท็จจริงที่ตัวจัดรูปแบบโค้ดไม่เข้าใจความสวยงามของการจัดรูปแบบโค้ด คุณมีตัวจัดรูปแบบรหัสกี่ครั้งที่ทำลายบล็อกความคิดเห็นที่จัดเรียงอย่างดีในรูปแบบตาราง คุณตั้งใจจัดนิพจน์ที่ซับซ้อนกี่ครั้งเพื่อเพิ่มความสามารถในการอ่านเพียงเพื่อให้การจัดรูปแบบอัตโนมัติทำให้เป็นสิ่งที่ "ตามกฎ" แต่สามารถอ่านได้น้อยกว่ามาก ?

บางครั้งมีวิธีแก้ไขปัญหาสำหรับสิ่งเหล่านี้ แต่นักพัฒนามีสิ่งที่สำคัญกว่าที่ต้องคำนึงถึงมากกว่าวิธีการจัดรูปแบบอัตโนมัติจากการจัดการโค้ด

มีกฎการจัดรูปแบบ แต่ให้อิสระในการใช้สามัญสำนึก

นักพัฒนาที่ดีคือคนที่มีความคิดสร้างสรรค์ "ทำให้ง่าย" ควรเป็นมนต์โปรแกรมเมอร์ ฉันมีกฎสองข้อ:

กฎที่ 1: ให้ตัวแปร / เคอร์เซอร์ / วัตถุ / ขั้นตอน / สิ่งที่ชื่อ SENSIBLE ชื่อที่ไม่คลุมเครือซึ่งนำความหมายและความเข้าใจมาสู่โค้ดของคุณ

กฎที่ 2: ใช้การเยื้องเพื่อแสดงโครงสร้างของรหัสของคุณ

แค่นั้นแหละ.

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

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

Google ได้ตีพิมพ์บทความเกี่ยวกับเรื่องนี้เรียกว่า"ที่ไหนมีหนี้รูปร่าง: ประสบการณ์การจัดการหนี้ทางเทคนิคที่ Google"

มันไม่ใช่ภาษารหัส มนุษย์เรามีมากกว่า 6,000 ภาษาดังนั้นเราจึงแปลมัน ดังนั้นหากคุณต้องการ "รหัส" เพื่อสื่อสารคุณจะต้องทำการปรับเปลี่ยน คุณเห็นว่าผู้ใช้ของเราต้องเปลี่ยนรูปแบบข้อมูลของเราดังนั้นเราจะไม่ทำให้ข้อมูลของเราหลวม

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

ปัญหาที่ใหญ่ที่สุดของฉันกับแนวคิดคือ

1. หากฉันเขียนโค้ดในรูปแบบเดียวและมีการฟอร์แมตใหม่โดยอัตโนมัติแรงจูงใจอะไรที่จะเรียนรู้รูปแบบนั้นจริง ๆ ?
2. ตามจุดก่อนหน้านั้นหากคุณไม่ได้เรียนรู้รูปแบบจุดการจัดรูปแบบอัตโนมัติทั้งหมด (เพื่อให้โค้ดอ่านและแก้ไขได้ง่ายขึ้น) จะหายไปอย่างสมบูรณ์ คุณยังต้องใช้เวลาในการพิจารณาการจัดรูปแบบตามที่คุณอ่านรหัสเพราะคุณไม่ได้เรียนรู้รูปแบบนั้น
3. ฉันคิดว่ามันจะเป็นประสบการณ์ที่สั่นสะเทือนในฐานะนักพัฒนาที่จะเขียนชั้นเรียนหนึ่งวันปิดมันแล้วกลับมาในวันถัดไปเพื่อดูว่ามันแตกต่างอย่างสิ้นเชิง นั่นหมายความว่าผู้อื่นไม่เพียง แต่ต้องเรียนรู้รหัสของคุณเท่านั้นคุณต้องเรียนรู้รหัสของคุณ
4. นอกจากนี้ยังสามารถกระตุ้นการเข้ารหัสขี้เกียจ แทนที่จะผลักดัน dev เพื่อเรียนรู้รูปแบบพวกเขาสามารถเขียนในรูปแบบใดก็ได้ภายใต้ดวงอาทิตย์และมันจะดูตามที่คนอื่น ๆ ต้องการโดยอัตโนมัติ สิ่งนี้จะกลับไปที่ # 2 ซึ่งคุณไม่ได้เรียนรู้สไตล์และยังไม่สามารถอ่านได้อย่างถูกต้อง

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

โดยทั่วไป: ให้ความรับผิดชอบกับพนักงานเพื่อเรียนรู้รูปแบบของ บริษัท อย่าบังคับให้รหัสของพวกเขาเป็นสิ่งที่มันไม่ใช่