การจัดรูปแบบรหัสเป็นสิ่งที่ไม่ดีเมื่อใช้ VCS?


24

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

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

ดังนั้นฉันถามอยู่เสมอว่าการจัดรูปแบบรหัสเป็นสิ่งที่ไม่ดีจริงหรือ ข้อกังวลของเขามีผลมากกว่าการอ่านให้แน่ใจหรือไม่


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

12
เครื่องมือเปรียบเทียบไฟล์ที่ดีส่วนใหญ่มีตัวกรองสำหรับ "ความแตกต่างที่ไม่สำคัญ" หรือ "ละเว้นช่องว่าง" บางรายการเช่น Beyond Compare จัดส่งพร้อมตัวกรองเฉพาะภาษาที่สร้างไว้ล่วงหน้า ใช้เพื่อประโยชน์ของคุณถ้าคุณมีมัน
Michael K

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

@Edgar: +1 VP กำลังจู้จี้จุกจิกเกินไป การอ่านครั้งแรก ... และตัวเลือกการละเว้นช่องว่างหมายความว่านี่ไม่ใช่เรื่องใหญ่ และมันก็หมายความว่ามีปัญหาที่ใหญ่กว่าเพราะส่วนที่เหลือของทีมไม่สนใจ VP ควรกังวลเกี่ยวกับเรื่องนี้มากกว่า
quick_now

คำตอบ:


41

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

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


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

1
+1: นอกจากนี้การใช้บางอย่างเช่น Stylecop หรือเครื่องมืออื่น ๆ ที่จัดรูปแบบอัตโนมัติและบังคับใช้สไตล์ จากนั้นซิงโครไนซ์การตั้งค่าระหว่างสมาชิกในทีมทั้งหมดเพื่อให้การจัดรูปแบบสอดคล้องกันกับทุกคนและคุณไม่จำเป็นต้องจำว่ากฎการจัดรูปแบบ "ถูกต้อง" คืออะไร
Ryan Hayes

3
หาก OP ถูกพิมพ์ซ้ำสำหรับการพยายามจัดรูปแบบเอกสารเดียวมีบางอย่างบอกฉันว่าเขาจะไม่สามารถแนะนำให้ใช้ StyleCop ได้
Wayne Molina

3
@gbjbaanb: ใช่ นี่คือเหตุผลที่ดีที่สุดในการตัดสินใจประเภทนี้ในช่วงเริ่มต้น โครงการที่ฉันดำเนินอยู่ตอนนี้มีการตรวจสอบการตั้งค่าตัวจัดรูปแบบ Eclipse ในที่เก็บเพื่อให้เรารู้ว่าทุกคนมีการตั้งค่าเดียวกัน
unholysampler

1
@quickly_now: นี่คือเหตุผลที่เรามีผู้จัดการที่มีสิทธิ์ยับยั้ง หากผู้คนไม่เห็นด้วยพวกเขาสามารถตัดสินใจได้
unholysampler

29

ไม่มีรหัสการจัดรูปแบบเป็นสิ่งที่สำคัญมาก อย่างไรก็ตามการทำคอมมิทควรกระทำในสองกลุ่ม:

  1. การเปลี่ยนแปลงเครื่องสำอาง - สิ่งใดก็ตามที่ทำให้โค้ดอ่านง่ายขึ้น
  2. การเปลี่ยนแปลงอื่น ๆ - ทุกอย่างที่มีผลต่อรหัส

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


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

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

10

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


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

2
ตกลง ฉันสงสัยว่าสภาพแวดล้อมของ OP เป็นหนึ่งในสถานที่คาวบอยเหล่านั้นที่มีมาตรฐานที่แยกออกไป
Wayne Molina

4

ฉันเป็นผู้จัดรูปแบบ nit-picker ด้วยดังนั้นนี่คือเคล็ดลับ:

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

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

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

  • รับเครื่องมือ diff ที่ดีที่สามารถทำเครื่องหมายตามภาษาของการเปลี่ยนแปลงที่สำคัญและการเปลี่ยนแปลงที่ไม่สำคัญ สิ่งที่ฉันชอบมากเกินไปนอกเหนือจากการเปรียบเทียบทำเครื่องหมายการเปลี่ยนแปลงรหัสจริงในหนึ่งสีและช่องว่าง / ความคิดเห็นเฉพาะความแตกต่างในอีก

แก้ไขอีกหนึ่งเคล็ดลับ:

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

ตราบใดที่คุณไม่รวมแท็ก VC ในไบนารี (หรือสร้างข้อมูล)
Vatine

2

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

  • คุณคือผู้จัดการที่พยายามสร้างมาตรฐานการเข้ารหัสของทีม
  • ผู้จัดการของคุณขอให้คุณล้างข้อมูลโค้ดให้เป็นไปตามมาตรฐานการเข้ารหัสของทีม
  • คุณกำลังล้างรหัสจากนักพัฒนาไม่ได้อยู่ในทีมของคุณอีกต่อไปเพื่อให้เป็นไปตามมาตรฐานการเข้ารหัสของทีม

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


"เบื้องหลังพวกเขา": สิ่งนี้กลับไปที่ประเด็นทางจิตวิทยาของการเป็นเจ้าของรหัส (หรือสงครามการพัฒนาสนามหญ้า)
ร. ว.

2
"รหัสของคนอื่น" เป็นวิธีที่น่าสนใจในการพูด ฉันทำงานกับผลิตภัณฑ์ของ บริษัท ของฉันรวบรวมจากรหัส บริษัท ที่ฉันเป็นเจ้าของซึ่งสมาชิกในทีมของฉันและฉันทำงาน มันไม่ได้อยู่เบื้องหลังพวกเขาในทุกวิถีทางที่จะแก้ไขให้เป็นมาตรฐานในขณะที่ทำงานกับมัน อย่างไรก็ตามฉันเห็นด้วยว่าทางออกที่ดีที่สุดคือการทำให้นักพัฒนาดั้งเดิมทำความสะอาดตามมาตรฐาน
Caleb Huitt - cjhuitt

@Caleb: ยากถ้าพวกเขาแค่ปฏิเสธ
quick_now

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

ในการสนทนาดั้งเดิมของ OP ฉันอ่านว่าเป็นสภาพแวดล้อมที่ไม่มีมาตรฐานการเข้ารหัส (หรือบังคับใช้ไม่ดี) นั่นคือสาเหตุที่ฉันตอบเช่นนั้น ในสภาพแวดล้อมนั้นผู้พัฒนารายหนึ่งไม่ควรกำหนดมาตรฐานของเขาให้กับผู้อื่น
cdk เลิก
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.