การจัดการโดยไม่ทราบชื่อพารามิเตอร์ของฟังก์ชันเมื่อคุณเรียกใช้

13

นี่คือปัญหาการเขียนโปรแกรม / ภาษาที่ฉันต้องการจะได้ยินความคิดของคุณ

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

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

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

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

func DrawRectangleClipped (rectToDraw, fillColor, clippingRect) {}

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

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

DrawRectangleClipped(deserializedArray[0], deserializedArray[1], deserializedArray[2])

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

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

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

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

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

programming-languages language-agnostic

— ดาร์วิน
แหล่งที่มา

2

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

— FrustratedWithFormsDesigner

1

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

— Doval

3

@Darwin ในการเขียนโปรแกรมเชิงฟังก์ชันฟังก์ชั่นทั้งหมดยังคงมีเพียง 1 อาร์กิวเมนต์ หากคุณต้องการส่งผ่าน "ข้อโต้แย้งหลาย ๆ " พารามิเตอร์มักจะเป็น tuple (ถ้าคุณต้องการให้พวกเขาได้รับคำสั่ง) หรือบันทึก (ถ้าคุณไม่ต้องการให้พวกเขาเป็น) นอกจากนี้ยังเป็นเรื่องเล็กน้อยที่จะสร้างฟังก์ชันรุ่นพิเศษได้ตลอดเวลาดังนั้นคุณสามารถลดจำนวนอาร์กิวเมนต์ที่จำเป็น ตั้งแต่สวยมากทุกภาษาทำงานให้ไวยากรณ์สำหรับ tuples และบันทึก bundling ค่าไม่เจ็บปวดและคุณได้รับองค์ประกอบฟรี (คุณสามารถฟังก์ชั่นห่วงโซ่ที่ tuples ผลตอบแทนกับผู้ที่ใช้ tuples.)

— Doval

1

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

— ดาร์วิน

4

ฉันคิดว่าคำตอบคือ "อย่าตั้งชื่อตัวแปรว่า 'deserializedArray'" หรือไม่?

— whatsisname

10

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

คำตอบของปัญหานี้ส่วนหนึ่งขึ้นอยู่กับภาษา ดังที่คุณกล่าวถึง C # ได้ตั้งชื่อพารามิเตอร์ การแก้ปัญหาของ Objective-C สำหรับปัญหานี้เกี่ยวข้องกับชื่อเมธอดที่อธิบายเพิ่มเติม ตัวอย่างเช่นstringByReplacingOccurrencesOfString:withString:เป็นวิธีที่มีพารามิเตอร์ที่ชัดเจน

ใน Groovy ฟังก์ชั่นบางอย่างใช้แผนที่เพื่อให้มีไวยากรณ์ดังนี้:

restClient.post(path: 'path/to/somewhere',
            body: requestBody,
            requestContentType: 'application/json')

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

แม้ในภาษาอย่าง Objective-C มันก็สมเหตุสมผลที่จะ จำกัด จำนวนพารามิเตอร์ เหตุผลหนึ่งคือพารามิเตอร์หลายตัวเป็นตัวเลือก ยกตัวอย่างให้ดู rangeOfString: และรูปแบบในNSString

รูปแบบที่ฉันมักใช้ใน Java คือการใช้คลาสสไตล์คล่องเป็นพารามิเตอร์ ตัวอย่างเช่น:

something.draw(new Box().withHeight(5).withWidth(20))

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

ตัวอย่าง Java ข้างต้นยังช่วยให้การเรียงลำดับพารามิเตอร์อาจไม่ชัดเจนเช่นกัน ปกติแล้วเราจะสันนิษฐานด้วยพิกัดที่ X มาก่อน Y และฉันเห็นความสูงก่อนความกว้างเป็นแบบแผน แต่ก็ยังไม่ชัดเจน ( something.draw(5, 20))

ฉันเคยเห็นฟังก์ชั่นบางอย่างเช่นกันdrawWithHeightAndWidth(5, 20)แต่ถึงแม้ว่าสิ่งเหล่านี้จะไม่สามารถใช้พารามิเตอร์มากเกินไปหรือคุณเริ่มสูญเสียความสามารถในการอ่าน

— เดวิดวี
แหล่งที่มา

2

การสั่งซื้อหากคุณดำเนินการตามตัวอย่าง Java ต่อไปอาจเป็นเรื่องยากมาก ตัวอย่างเช่นเปรียบเทียบ constructor ต่อไปนี้จาก awt: Dimension(int width, int height)และGridLayout(int rows, int cols)(จำนวนแถวคือความสูงหมายถึงGridLayoutมีความสูงก่อนและDimensionความกว้าง)

— Pierre Arlaud

1

ไม่สอดคล้องกันดังกล่าวยังได้รับการวิพากษ์วิจารณ์มากกับ PHP ( eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design ) ตัวอย่างเช่น: array_filter($input, $callback)เมื่อเทียบกับarray_map($callback, $input), strpos($haystack, $needle)เมื่อเทียบกับarray_search($needle, $haystack)

— ปิแอร์ Arlaud

12

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

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

rect.clip(clipRect).fill(color)

แม้ว่าclipRectและcolorจะมีชื่อที่แย่ (และพวกเขาไม่ควร) คุณยังสามารถแยกแยะประเภทของพวกเขาจากบริบท

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

(rect, clipRect, color) = deserializeClippedRect()
rect.clip(clipRect).fill(color)

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

— Karl Bielefeldt
แหล่งที่มา

1

ฉันชอบความคิดที่จะใช้การเรียกหลายฟังก์ชั่นเพื่ออธิบายความหมาย แต่นั่นไม่ใช่แค่การแก้ไขปัญหาเหรอ? โดยพื้นฐานแล้ว "ฉันต้องการเขียนประโยค แต่ภาษาที่ฉันฟ้องร้องจะไม่ให้ฉันดังนั้นฉันจึงสามารถใช้สิ่งที่ใกล้เคียงที่สุดได้"

— ดาร์วิน

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

— maaartinus

3

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

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

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

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

— ดาร์วิน

ยินดีต้อนรับสู่หัวข้อทั่วไปของภาษาโดเมนเฉพาะสิ่งที่ฉันจริงๆหวังว่าผู้คนมากขึ้นจะเข้าใจประโยชน์ของ ... (+1)

— Izkata

2

ยกตัวอย่างเช่นในJavascript (หรือECMAScript ) โปรแกรมเมอร์จำนวนมากเริ่มคุ้นเคยกับ

ผ่านพารามิเตอร์เป็นชุดของคุณสมบัติวัตถุที่มีชื่อในวัตถุที่ไม่ระบุชื่อเดียว

และจากการฝึกเขียนโปรแกรมมันได้จากโปรแกรมเมอร์ไปยังไลบรารีของพวกเขาและจากที่นั่นไปยังโปรแกรมเมอร์คนอื่น ๆ ที่ชอบและใช้มันและเขียนไลบรารีเพิ่มเติมเป็นต้น

ตัวอย่าง

แทนการโทร

function drawRectangleClipped (rectToDraw, fillColor, clippingRect)

แบบนี้:

drawRectangleClipped(deserializedArray[0], deserializedArray[1], deserializedArray[2])

ซึ่งเป็นรูปแบบที่ถูกต้องและถูกต้องคุณเรียกใช้

function drawRectangleClipped (params)

แบบนี้:

drawRectangleClipped({
    rectToDraw: deserializedArray[0], 
    fillColor: deserializedArray[1], 
    clippingRect: deserializedArray[2]
})

ซึ่งถูกต้องและถูกต้องและดีเกี่ยวกับคำถามของคุณ

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

— พาเวล
แหล่งที่มา

ฉันไม่รู้เกี่ยวกับภาษานั้นพอที่จะตรวจสอบไวยากรณ์ แต่โดยรวมแล้วฉันชอบโพสต์นี้ ดูเหมือนว่าสวยสง่า +1

— ไอทีอเล็กซ์

บ่อยครั้งสิ่งนี้จะถูกรวมเข้ากับอาร์กิวเมนต์ปกติเช่นมี 1-3 อาร์กิวเมนต์ตามด้วยparams(มักจะมีอาร์กิวเมนต์ที่เป็นตัวเลือกและมักจะเป็นทางเลือก) เช่นเช่นฟังก์ชันนี้ สิ่งนี้ทำให้ฟังก์ชั่นที่มีข้อโต้แย้งมากมายเข้าใจง่าย (ในตัวอย่างของฉันมีข้อโต้แย้งบังคับ 2 ข้อและตัวเลือก 6 ข้อ)

— maaartinus

0

คุณควรใช้ object-C ดังนั้นนี่คือคำจำกัดความของฟังก์ชัน:

- (id)performSelector:(SEL)aSelector withObject:(id)anObject withObject:(id)anotherObject

และนี่มันถูกใช้:

[someObject performSelector:someSelector withObject:someObject2 withObject:someObject3];

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

สำหรับฟังก์ชันที่ซับซ้อนใน Java ฉันต้องการกำหนดตัวแปรจำลองในการใช้ฟังก์ชัน สำหรับตัวอย่างซ้ายขวาของคุณ:

Rectangle referenceRectangle = leftRectangle;
Rectangle targetRectangle = rightRectangle;
doSomeWeirdStuffWithRectangles(referenceRectangle, targetRectangle);

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

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

เกี่ยวกับตัวอย่าง Java ที่ฉันเขียนในคำถามว่าทำไมฉันคิดว่ามันไม่ใช่ทางออกที่ดี คุณคิดยังไงเกี่ยวกับที่?

— ดาร์วิน

0

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

ตัวอย่าง (C ++):

auto& connector_source = deserializedArray[0]; 
auto& connector_target = deserializedArray[1]; 
auto& bounding_box = deserializedArray[2]; 
DoWeirdThing(connector_source, connector_target, bounding_box)

และฉันอาจจะเขียนฟังก์ชั่น wrapper หนึ่งซับหรือแม่แบบ:

template <typename T1, typename T2, typename T3>
draw_bounded_connector(
    T1& connector_source, T2& connector_target,const T3& bounding_box) 
{
    DoWeirdThing(connector_source, connector_target, bounding_box)
}

(เพิกเฉยต่อแอมเปอร์แซนด์ถ้าคุณไม่รู้ C ++)

หากฟังก์ชั่นทำสิ่งแปลก ๆ หลายอย่างโดยไม่มีคำอธิบายที่ดี - มันอาจต้องได้รับการฟื้นฟูอีกครั้ง!

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