ข้อดีและข้อเสียของการจัดรูปแบบรหัสแบบบังคับ

ฉันกำลังทำงานในสถานที่ที่อาจมองหาการบังคับให้นักพัฒนาใช้ฟอร์แมตโค้ดอัตโนมัติในการเช็คอินการควบคุมเวอร์ชัน ฉันกำลังมองหาความคิดเห็นของนักพัฒนาเกี่ยวกับข้อดีและข้อเสียของการทำสิ่งนี้ ... วิธีที่คุณคิดว่ามันจะช่วยหรือขัดขวางนักพัฒนา กรณีเฉพาะของฉันเกี่ยวข้องกับ Java / JSP แต่ฉันคิดว่าคำถามนี้สามารถใช้ได้กับทุกภาษา

ฉันคิดว่ามันสำคัญมากที่จะทำสิ่งนี้ นี่คือเหตุผล:

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

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

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

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

• กำจัดความสามารถในการทำ 'ดีกว่า' ตัวจัดรูปแบบอัตโนมัติ ... มันจะยกเลิกการจัดรูปแบบที่สะอาดกว่าของคุณ ตัวอย่างนี้จะเป็นการประกาศพารามิเตอร์ตามคอลัมน์รายการของการเพิ่มของวัตถุโดยสิ้นเชิงเป็นต้น
• สร้างความต้านทานต่อการเปลี่ยนสไตล์การประชุมเนื่องจากสิ่งเหล่านี้จะสร้างการเปลี่ยนแปลงที่แตกต่างที่ทำให้เข้าใจผิดขนาดใหญ่
• ลบความสามารถในการจัดรูปแบบ 'กรณีพิเศษ' ที่รูปแบบทางเลือกอื่นจะทำให้โค้ดอ่านง่ายขึ้น
• มันผูกคุณในการใช้ IDEs ที่สนับสนุนว่าการจัดรูปแบบที่มีคุณสมบัติที่คุณต้องการ ใน IDE ตัวอื่นหายไปหนึ่งในตัวเลือกที่คุณต้องการมันจะทำให้เกิดปัญหาอย่างน้อย
• มันจะกลายเป็นปัญหาในการแบ่งปันพื้นที่เก็บข้อมูลรหัสที่เขียนได้กับกลุ่มภายนอกเว้นแต่พวกเขาจะใช้รูปแบบการประชุมที่เหมือนกันกับกลุ่มของคุณ (มักจะเป็น แต่ไม่เสมอไป)
• จะมีข้อยกเว้นเสมอซึ่งรูปแบบที่แตกต่างกันเล็กน้อยน่าจะสะอาดกว่าสไตล์ที่กำหนดไว้ การแปลงอัตโนมัติมักจะซ่อนเจตนาของบล็อคโค้ดบางอย่างซึ่งมีผลดีพอ ๆ กับการเพิ่มข้อบกพร่องให้กับโค้ด

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

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

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

ข้อเสียเปรียบหลักคือการสูญเสียการจัดรูปแบบที่กำหนดเองซึ่งสำคัญมาก

ลองนึกภาพการตรวจสุขภาพจิตโดยทั่วไปหาก () ที่จะล้มเหลวหากมีเงื่อนไขใด ๆ เกิดขึ้น แต่ไม่สำเร็จ ...

  if(
      (user.id == TEST_ID)
    ||(
         (user.id == UserID)
       &&( 
             ( user.type == HUMAN_USER && user.name.size() >= MIN_NAME )
           ||( user.type == EMULATION && input.source != SOURCE_INTERNAL ))
       && ( user.email == NULL || emailValidator.isValid(user.email))
       && ( (user.phone == NULL) == (user.type == EMULATION) )

       // several more lines like this.)
    ){ /* handle results */ }

สิ่งนี้สามารถอ่านได้ด้วยการเยื้องที่สมเหตุสมผลตามโครงสร้างตรรกะของเงื่อนไข

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

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

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

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

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

พิจารณากรณีนั้น:

if( x == 0 ) 
   return foo;
//do something else
return bar;

หากคุณต้องการเพิ่มการบันทึกบางส่วนในกรณี if คุณอาจเขียนโดยไม่ได้ตั้งใจ:

if( x == 0 ) 
  log.info("x was 0");
  return foo;
//do something else
return bar;

และ suddently fooวิธีการของคุณเสมอกลับ

แก้ไข: นั่นไม่ใช่การจัดรูปแบบอัตโนมัติ แต่เป็นการตรวจสอบสไตล์ ขออภัยถ้าคำตอบนั้นเป็นหัวข้อนอกเช่นกัน :)

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

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

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