อาร์กิวเมนต์ที่ระบุชื่อ (พารามิเตอร์) เป็นตัวช่วยการอ่าน

11

นานมาแล้วฉันตั้งโปรแกรมมากใน ADA และเป็นเรื่องปกติที่จะตั้งชื่ออาร์กิวเมนต์เมื่อเรียกใช้ฟังก์ชัน - SomeObject.DoSomething (SomeParameterName => someValue);

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

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

contentFetcher.DownloadNote (หมายเหตุ, คู่มือ: จริง);

ฉันเดาว่าฉันสามารถสร้าง Enums แทนการใช้จริงหรือเท็จ (Manual, Automatic ในกรณีนี้)

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

coding-style

— เดเมียน
แหล่งที่มา

ความคิดเห็นพารามิเตอร์ด้านบนของวิธีการยังช่วย

— Amir Rezaei

1

@ amir-rezaei: ความคิดเห็นเกี่ยวกับพารามิเตอร์ที่ด้านบนของวิธีการจะช่วยได้ก็ต่อเมื่อคุณสามารถเชื่อถือความคิดเห็นได้ ถ้าคุณไม่มีนักพัฒนาที่ดีและกระบวนการตรวจสอบโค้ดที่ดีฉันจะไม่เชื่อความคิดเห็น

— btilly

ในฐานะผู้ใช้ Ada เพียงครั้งเดียวฉันใช้เพื่อการใช้งานตามที่คุณอธิบายเป็นครั้งคราว นั่นเป็นวิธีที่ฉันจำได้ว่ามันถูกใช้ใน Ada, BTW - ฉันจะไม่เรียกมันว่า "ผิดปกติ" แต่คำว่า "ปกติ" ดูเหมือนจะบอกเป็นนัยถึงการโทรส่วนใหญ่จะระบุชื่อพารามิเตอร์ซึ่งไม่ใช่วิธีที่ฉันจำได้ แน่นอนว่าการประชุมนั้นแตกต่างกันไป แต่ความยุ่งเหยิงที่ไม่จำเป็นเป็นข้อตกลงที่ไม่ดีใน IMO ภาษาใด ๆ

— Steve314

ฉันเห็นด้วยว่าการใช้งานของคุณใน Ada ไม่ใช่สิ่งที่เราทำตลอดเวลา แต่ช่วยได้

— เดเมียน

7

สิ่งนี้ถูกแนะนำในการพัฒนา C ++ และ Stroustrup กล่าวถึงใน "การออกแบบและวิวัฒนาการของ C ++" ของเขาหน้า 153 และต่อไปนี้ ข้อเสนอนั้นมีรูปแบบที่ดีและมีประสบการณ์ก่อนหน้านี้กับ Ada มันไม่ได้เป็นลูกบุญธรรม

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

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

นอกจากนี้ยังสามารถจัดการโดยใช้วัตถุแทนการเรียกใช้ฟังก์ชัน แทนการเรียก GetWindow ด้วยพารามิเตอร์โหลสร้างคลาสหน้าต่างด้วยตัวแปรส่วนตัวโหลและเพิ่มตัวตั้งค่าตามความจำเป็น โดยการผูกมัด setters my_window.SetColor(green).SetBorder(true).SetBorderSize(3);มันเป็นไปได้ที่จะเขียนสิ่งที่ต้องการ นอกจากนี้ยังเป็นไปได้ที่จะมีฟังก์ชั่นที่แตกต่างกับค่าเริ่มต้นที่แตกต่างกันที่เรียกใช้ฟังก์ชั่นที่ใช้งานได้จริง

หากคุณกังวลเกี่ยวกับผลกระทบของเอกสารcontentFetcher.DownloadNote(note, manual : true);คุณสามารถเขียนสิ่งที่ชอบได้contentFetcher.DownloadNote(note, /* manual */ true);ตลอดเวลาดังนั้นจึงไม่มีประโยชน์ในการจัดทำเอกสาร

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

สนุกพอเมื่อฉันย้ายจาก Ada เป็น C ฉันเริ่มใช้การประชุมที่คุณอธิบาย - ผู้ตรวจสอบโค้ดเกลียดมัน ยอมรับว่าไม่ได้ใช้มันสำหรับพารามิเตอร์จำนวนมาก

— เดเมียน

7

ฉันคิดว่านี่เป็นปัญหาของการทำให้โค้ดไม่ดีสามารถอ่านได้มากกว่า "วิธีปฏิบัติที่ดีที่สุด"

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

เมื่อเมธอดมีพารามิเตอร์ 1 หรือ 2 เท่านั้นและชัดเจนจากชื่อเมธอดว่าพารามิเตอร์คืออะไรพารามิเตอร์ที่มีชื่อจะไม่เพิ่มอะไรเลย นี่เป็นกรณีที่เหมาะสำหรับการเข้ามา

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

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

1

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

— Steve314

1

@ Steve314 ตัวอย่าง:void TrackDataChange(Data oldData, Data newData)

— Alexander

3

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

public Content DownloadNote(Note note)
{
    return downloadNote(note, manual: false);
}

public Content DownloadNoteManually(Note note)
{
    return downloadNote(note, manual: true);
}

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

— Scott Whitlock
แหล่งที่มา

3

หากคุณมีตัวเลือก x คุณจะสร้างส่วนหน้า 2 ^ x ได้หรือไม่

— apoorv020

@ apoorv020 - ถ้าฉันมีพารามิเตอร์เพียงพอที่จะเรียกเมธอดที่ 2 ^ x มีนัยสำคัญฉันจะสร้างคลาสใหม่เพื่อเก็บค่าพารามิเตอร์และเพียงผ่านพารามิเตอร์หนึ่งตัว

— Scott Whitlock

@ scott-whitlock: ตัวเลือก 1 - สร้างวัตถุตั้งค่าคุณสมบัติ x เรียกใช้เมธอดหนึ่งครั้งกับวัตถุของคุณ ตัวเลือก 2 - เรียกใช้เมธอดที่มีพารามิเตอร์ที่มีชื่อ x สิ่งไหนดีกว่านั้นขึ้นอยู่กับภาษาของคุณ ในภาษาที่พิมพ์แบบไดนามิกตัวเลือก 1 ต้องใช้หม้อไอน้ำมากขึ้นอย่างมีนัยสำคัญโดยไม่ได้รับและยิ่งแย่ลง ในภาษาที่พิมพ์แบบคงที่คุณยังคงเพิ่มสำเร็จรูป แต่การทดสอบสำหรับคีย์ที่มีชื่อไม่ถูกต้องจะต้องทำในเวลารวบรวมมากกว่าเวลาทำงาน ดังนั้นตัวเลือกที่ 1 จะดีกว่าใน C # แต่ตัวเลือกที่ 2 เป็นการชนะที่ชัดเจนใน Python

— btilly

@btilly - ตามที่เอียนชี้ให้เห็นชัดเจนรหัสสะอาดบอกคุณว่าไม่มีฟังก์ชั่นที่มีพารามิเตอร์มากกว่า 2 หรือ 3 ตัว เพื่อความยุติธรรมมันถูกจัดการกับ Java ซึ่งพิมพ์แบบคงที่ OP ยังถามเกี่ยวกับ C # ซึ่งพิมพ์แบบคงที่ ฉันยังคงต้องการใช้ฟังก์ชั่นโอเวอร์โหลดและ / หรือชื่อฟังก์ชั่นที่มีชื่อแม่นยำแตกต่างกันกว่ารายการพารามิเตอร์ยาว

— Scott Whitlock

@ scott-whitlock: พวกเราไม่เห็นด้วยหรือเปล่า เราเห็นด้วยกับสิ่งที่ดีที่สุดใน C # เราทั้งคู่ต่างรู้ว่า Clean Code บอกอะไร ประเด็นของฉันคือมันเป็นสิ่งสำคัญที่จะต้องเข้าใจว่าทำไมมันจึงเป็นสิ่งที่ดีเพื่อให้คุณรู้ว่าคำแนะนำเมื่อใดหรือไม่เหมาะสมกับสภาพแวดล้อมที่แตกต่างกัน

— btilly

3

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

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

— ยูริ
แหล่งที่มา

0

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

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

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