แก้ไขข้อผิดพลาดการสะกดคำในชื่อวิธีการ

73

หนึ่งในวิธีการที่ฉันใช้กันทั่วไปใน codebase ของเราคือการสะกดคำผิด

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

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

refactoring

— หนึ่งสองสาม
แหล่งที่มา

12

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

16

* สะกดผิด และคุณจะต้องเปลี่ยนทุกที่ที่มีการเรียกใช้

— JohnP

2

* สะกดผิด ... หรืออาจเป็นตัวสะกดที่ต่างออกไป?

— HorusKol

2

@ JohnP มีสามตอนนี้หนึ่งได้รับการแก้ไขและสองยังคงไม่ถูกต้อง เหมาะกับชื่อของ OP ค่อนข้างบังเอิญ :)

— ไม่แยแส

3

เราต้องไม่ยอมให้มีการสะกดคำผิดอะไร

— Magus

136

ฉันควรใช้โอกาสที่จะเปลี่ยนชื่อวิธีการที่เลวร้ายหรือไม่?

อย่างแน่นอน

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

— Telastyn
แหล่งที่มา

33

แนวคิดของ "การส่งต่อไปยังวิธีการตั้งชื่ออย่างถูกต้อง" นั้นเรียบง่ายและยอดเยี่ยม ลิงก์ที่น่าสนใจเกี่ยวกับทฤษฎีหน้าต่างแตกเช่นกัน

— dev_feed

2

โปรดทราบว่าหากนี่เป็นส่วนหนึ่งของ API สาธารณะนี่อาจไม่ใช่การเปลี่ยนแปลงที่เข้ากันได้ย้อนหลัง (ขึ้นอยู่กับภาษา) นี่ไม่น่าเป็นไปได้อย่างที่มันอาจฟังดู .. ถ้าฉันต้องสืบทอดจาก API ที่มีอยู่ด้วยชื่อที่สะกดผิดฉันจะต้องแก้ไขอย่างแน่นอน

— Voo

10

@voo - ใช่มั้ย ภาษาใดที่ทำให้การเพิ่มวิธีการใหม่ (และการเปลี่ยนการใช้งานของหนึ่งเพื่อทำพฤติกรรมที่แน่นอนเดียวกัน) ไม่เข้ากันได้ย้อนหลัง?

— Telastyn

3

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

— jwenting

17

@Telastyn หากชื่อเมธอด misspelt อยู่บนอินเทอร์เฟซ (เช่นในประเภทอินเตอร์เฟสที่ใช้ใน Delphi / Java / C #) ดังนั้นการเพิ่มชื่อที่สะกดอย่างถูกต้องจะทำให้การใช้งานที่มีอยู่ทั้งหมดของอินเตอร์เฟสดังกล่าว

— ไม่แยแส

52

มีหลายกรณีที่คุณควรหลีกเลี่ยงการปรับโครงสร้างเช่น:

หากวิธีการที่ใช้ในส่วนต่อประสานสาธารณะ ตัวอย่างที่ยอมรับได้คือการสะกดคำผิดของผู้อ้างอิงในHTTP refererซึ่งเป็นการสะกดผิดเนื่องจากการเปลี่ยนการสะกดตอนนี้จะส่งผลกระทบมากเกินไป
หากรหัสฐานไม่ครอบคลุมโดยการทดสอบใด ๆ การปรับโครงสร้างใด ๆควรทำในรหัสที่ผ่านการทดสอบเพื่อให้สามารถทำการทดสอบการถดถอยได้ การปรับฐานรหัสใหม่ซึ่งไม่ได้อยู่ในการทดสอบนั้นมีความเสี่ยงเป็นพิเศษ หากคุณมีเวลามากให้เริ่มจากการเพิ่มการทดสอบ หากคุณทำงานภายใต้แรงกดดันด้านเวลาการเสี่ยงต่อการแนะนำข้อบกพร่องเล็กน้อยนั้นไม่ใช่วิธีที่ดีที่สุดถ้าคุณต้องการจัดส่งตรงเวลา
หากวิธีการนี้สามารถใช้ในลักษณะที่ผิดปกติซึ่งทำให้การใช้งานเป็นไปไม่ได้ที่จะหาได้จริง (ผ่าน Ctrl + F หรือโดยเครื่องมือการเปลี่ยนโครงสร้างอัตโนมัติ) ตัวอย่างเช่นใน C # วิธีการสามารถเรียกผ่านการสะท้อนทำให้การเปลี่ยนชื่อโต้ตอบของ Visual Studio ไม่ได้ผล ใน JavaScript ฟังก์ชั่นที่เรียกว่า Inside eval()นั้นหายากเช่นกัน ใน PHP ตัวแปรตัวแปรอาจทำให้เกิดปัญหา
ถ้าขนาดของโครงการมีขนาดใหญ่และทีมอื่น ๆ สามารถใช้วิธีการนี้ได้ สิ่งนี้คล้ายกับจุดแรกเช่นอินเทอร์เฟซที่คุณให้กับทีมอื่น ๆ อาจถือเป็นส่วนต่อประสานสาธารณะ
หากคุณจัดการกับโครงการที่สำคัญต่อชีวิต โอกาสการสะกดผิดนั้นไม่สำคัญเกินกว่าที่จะพิสูจน์เอกสารสองสามเดือนเพื่อเปลี่ยนชื่อของวิธีการและทำให้แน่ใจว่าจะไม่ทำให้ผู้ป่วยได้รับรังสีที่ได้รับอนุญาตหรือกระสวยใด ๆ สิบเท่าเพื่อคำนวณความเร็วของมัน

ในสถานการณ์อื่น ๆ อย่าลังเลที่จะเปลี่ยนชื่อวิธี

— Arseni Mourzenko
แหล่งที่มา

1

+1 สำหรับความคิดเห็นที่กล่าวถึง Reflection มันกัดฉันมากกว่าหนึ่งครั้ง

— DaveShaw

33

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

— user2357112

2

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

— user2357112

8

@ user2357112: ฉันไม่เคยพูดว่าการปรับโครงสร้างเพียงเล็กน้อยนั้นน่าจะฆ่าใครซักคน มันไม่ได้เกี่ยวกับการฆ่าใครบางคน แต่เกี่ยวกับการทำให้ทุกอย่างเป็นไปได้เพื่อลดความเสี่ยง 0.001% ที่เหลือจากการมีข้อบกพร่อง สิ่งนี้ต้องใช้ proff อย่างเป็นทางการ สิ่งนี้ต้องการการทดสอบหลายระดับ สิ่งนี้ต้องใช้แบบแผน ห้ามนี้ "ฉันต้องการเปลี่ยนชื่อวิธีนี้อย่างรวดเร็วหวังว่ามันจะใช้ได้!" พฤติกรรม. โครงการที่สำคัญต่อชีวิตใช้เทคนิคที่จะถือว่าเป็นการเสียเวลาและเงินอย่างสมบูรณ์สำหรับแอพทางธุรกิจใด ๆ นั่นเป็นเหตุผลที่พวกเขาเชื่อถือได้ (และแพง)

— Arseni Mourzenko

5

@ user2357112: ตามที่ MainMa ชี้ให้เห็นมันไม่ได้เกี่ยวกับแอพทางธุรกิจทั่วไป เป็นซอฟต์แวร์ประเภทพิเศษที่มีการทดสอบ / ตรวจสอบอย่างกว้างขวาง เกิดอะไรขึ้นถ้าวิธีการที่ถูกเรียกโดยสะท้อนบาง จะเกิดอะไรขึ้นถ้าเครื่องมือคอมไพล์ก่อน / หลังการโพสต์ทำอะไรกับมันบ้าง เอกสารเกี่ยวกับอะไร? แล้วทีมอื่นที่ใช้มันล่ะ พวกเขาใช้การสะท้อน? เกิดอะไรขึ้นถ้า ... ชีวิตจริงอาจมีความซับซ้อน และบางครั้งมันก็เป็นการดีกว่าที่จะปล่อยให้ชื่อเมธอดไม่มีการแตะต้องแทนที่จะยืนยันว่ามีผลกระทบใด ๆ ในลักษณะที่เป็นสัญลักษณ์แสดงหัวข้อย่อย

— dagnelies

30

ฉันทำสิ่งนี้เมื่อไม่กี่เดือนที่ผ่านมา (ด้วยเหตุผลอื่น) ขั้นตอนที่ฉันทำ (ภาษาคือ Perl):

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

แน่นอนว่าระยะทางของคุณจะแตกต่างกันไป

— Abigail
แหล่งที่มา

การปรับปรุงหนึ่งอย่าง - ไม่ต้องพึ่งพา grep เพื่อค้นหาผู้ใช้ชื่อเดิมรวมทั้งล็อกอินภายในผู้ส่ง

— Ben Voigt

@BenVoigt นั่นไม่ใช่สิ่งที่ # 4 ทำใช่ไหม

— Bob

6

วิธีที่ดีที่จะไม่ทำลายรหัสใด ๆ ที่มีอยู่ก็คือการโยงชื่อวิธีการใหม่ไปยังตัวเก่าในเช่น

private void MyNewMethodName()
{
    TheOldMethodName();
}

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

/ แก้ไขตามที่ ivo กล่าวไว้ในความคิดเห็น: สิ่งที่ดียิ่งกว่าคือการย้ายโค้ดจากTheOldMethodNameลงในMyNewMethodNameและเรียกวิธีการใหม่จากเก่า อันนี้ก็มีข้อได้เปรียบที่จะช่วยให้ dev รับหัวของพวกเขาที่เป็นของรหัส

— Rémi
แหล่งที่มา

2

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

— Ivo Limmen

1

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

— Rémi

1

เปลี่ยนชื่อวิธี:

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

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

— อ่อน
แหล่งที่มา

0

ฉันมักจะแนะนำใช่เปลี่ยนชื่อมัน

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

— ไบรอัน
แหล่งที่มา