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

มีวิธีที่ดีกว่าในการทำเช่นนี้? มีวิธี "การปฏิบัติที่ดีที่สุด" ในการสั่งซื้อพารามิเตอร์ที่ช่วยเพิ่มความชัดเจนหรือไม่?

โดยทั่วไป: ใช้มัน

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

และดูตามลำดับที่คุณวางไว้

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

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

หลีกเลี่ยงความสับสนเพื่อนร่วมงานของคุณและตัวคุณในอนาคต

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

ช่องทางที่เลือก

1. อรรถศาสตร์
2. ความสำคัญ / ความเกี่ยวข้อง
3. ความถี่ในการใช้งาน
4. ข้อกังวลของ I / O

1. ความหมายก่อน

โดยเฉพาะอย่างยิ่งใน OOP เลือกพารามิเตอร์ตามความหมายเชิงความหมายสำหรับการกระทำหรือข้อความ ลายเซ็นของวิธีที่มีชื่อพร้อมพารามิเตอร์ที่มีชื่อดีควร:

• รู้สึกเป็นธรรมชาติที่จะโทร
• จงอธิบายตัวเองในแง่ของเจตนาและพฤติกรรม

(ด้วยเหตุผลเหล่านี้บางครั้งการใช้ประเภทที่กำหนดเองหรือนามแฝงแทนดั้งเดิมอาจเพิ่มความหมายของลายเซ็นของคุณ)

2. จากนั้นความสำคัญ

พารามิเตอร์ "ที่สำคัญที่สุด" มาก่อน (หรือถัดไป ... )

3. จากนั้นความถี่

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

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

4. อย่าลืม I / O

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

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

(สังเกตุฉันไม่ได้พูดถึงตัวแปรทั่วโลกเพราะเหตุใดคุณจะใช้อย่างใดอย่างหนึ่งใช่มั้ย)

บางสิ่งที่ต้องพิจารณา

• การใช้งาน

  ส่วนใหญ่ข้างต้นจะแสดงตามธรรมชาติถ้าคุณทำตามคำแนะนำของ ZJR : ใช้มัน!

• พิจารณาการปรับโครงสร้างใหม่

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

• พิจารณาประสิทธิภาพ

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

• คำตอบและการกล่าวถึงคำแนะนำของClean Codeของ Bevan นั้นมีความเกี่ยวข้องเช่นกัน!

ฉันขอแสดงความนับถือว่าการกังวลเกี่ยวกับการสั่งซื้อพารามิเตอร์กำลังกังวลเกี่ยวกับสิ่งที่ผิด

ในหนังสือของลุงบ็อบ " Clean Code " เขาสนับสนุนอย่างโน้มน้าวใจว่าวิธีการไม่ควรมีมากกว่าสองข้อโต้แย้ง - และส่วนใหญ่ควรมีเพียงหนึ่งเดียวถ้ามี ในกรณีนี้การสั่งซื้ออาจชัดเจนหรือไม่สำคัญ

อย่างไรก็ตามไม่สมบูรณ์ฉันพยายามทำตามคำแนะนำของลุงบ๊อบ - และมันกำลังปรับปรุงโค้ดของฉัน

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

ฉันพยายามใส่พารามิเตอร์ IN ก่อนพารามิเตอร์ OUT สอง นอกจากนี้ยังมีการสั่งซื้อจากธรรมชาติเช่นเป็นอย่างยิ่งที่จะcreatePoint(double x, double y) preferrablecreatePoint(double y, double x)

ฉันไม่เคยเห็นเอกสาร "แนวปฏิบัติที่ดีที่สุด" ที่มีเอกสารเกี่ยวกับหัวข้อเฉพาะนี้ แต่มาตรฐานส่วนบุคคลของฉันคือการแสดงรายการไว้ตามลำดับที่ปรากฏในวิธีการใช้งานหรือหากวิธีนั้นมีมากกว่า ส่งผ่านไปยังชั้นข้อมูลฉันจะแสดงรายการพวกเขาตามลำดับที่พวกเขาจะปรากฏใน db schema หรือวิธีชั้นข้อมูล

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

void func1(string param) { }
void func2(string param, int param2) { }
void func3(string param, string param3) { }
void func3(string param, int param2, string param3) { }

คำสั่ง: อินพุต, เอาต์พุต, พารามิเตอร์เสริม

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

http://msdn.microsoft.com/en-us/library/zthk2dkh%28v=vs.80%29.aspx

http://en.wikipedia.org/wiki/Calling_convention

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

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

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

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

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

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

มีวิธีที่ดีกว่าในการทำเช่นนี้? มีวิธี "การปฏิบัติที่ดีที่สุด" ในการสั่งซื้อพารามิเตอร์ที่ช่วยเพิ่มความชัดเจนหรือไม่?

มีหลายวิธี:

a) ตัวเล็กตัวน้อย: อย่าใช้มากกว่าหนึ่งพารามิเตอร์

ข) ในขณะที่คุณไม่ได้ระบุสิ่งที่ภาษาที่คุณได้เลือกที่มีโอกาสที่คุณเลือกภาษาที่มีชื่อพารามิเตอร์ นี่คือน้ำตาล syntactic ที่ดีซึ่งช่วยให้คุณคลายความสำคัญของการเรียงลำดับของพารามิเตอร์:fn(name:"John Doe", age:36)

ไม่ใช่ทุกภาษาที่อนุญาตให้มีนิสัยดังกล่าว ถ้าเช่นนั้นจะเป็นอย่างไร

c) คุณสามารถใช้Dictionary / Hashmap / Associative Arrayเป็นพารามิเตอร์: เช่น Javascript จะอนุญาตสิ่งต่อไปนี้: fn({"name":"John Doe", age:36})ซึ่งอยู่ไม่ไกลจาก (b)

d) แน่นอนถ้าคุณทำงานกับภาษาที่พิมพ์แบบคงที่เช่น Java คุณสามารถใช้Hashmapได้ แต่คุณจะพิมพ์ข้อมูลหลวม ๆ (เช่นเมื่อทำงานด้วยHashMap<String, Object>) เมื่อพารามิเตอร์มีประเภทที่แตกต่างกัน (และจำเป็นต้องส่ง)

ตรรกะขั้นตอนต่อไปจะผ่านObject(ถ้าคุณกำลังใช้ Java) ที่มีคุณสมบัติเหมาะสมหรือบางสิ่งบางอย่างที่มีน้ำหนักเบามากขึ้นเช่นstruct (ถ้าคุณเขียนเช่น C # หรือ C / C ++)

หลักการง่ายๆ:

1) กรณีที่ดีที่สุด - วิธีการของคุณไม่มีพารามิเตอร์เลย

2) กรณีที่ดี - วิธีการของคุณต้องการหนึ่งพารามิเตอร์

3) กรณีที่ทนได้ - วิธีการของคุณต้องการพารามิเตอร์สองตัว

4) กรณีอื่น ๆ ทั้งหมดควรจะ refactored

บ่อยครั้งที่วัตถุที่ซับซ้อนในฐานะพารามิเตอร์ดีกว่า - พารามิเตอร์ที่มีชื่อรุ่นของคนจนที่ทำงานบนแพลตฟอร์มส่วนใหญ่ และเปิดประตูสู่พารามิเตอร์ที่มีพฤติกรรมในการบู๊ต

ตัวอย่างของสิ่งส่วนใหญ่ที่คุณไม่ควรทำคุณอาจต้องการลองอ่านเอกสารมาตรฐานของ PHP

ฉันมักจะสั่งให้พวกเขาด้วยสิ่งที่จำเป็นก่อนโดยการวัดรวมของความสำคัญและความถี่ในการใช้งานตาม "ความรู้สึก" (สามารถมองเห็นได้ORDER BY required DESC, SOME_MAGIC_FEELING(importancy,frequency)) และไม่เป็นไปตามการปฏิบัติที่เฉพาะเจาะจงใด ๆ

อย่างไรก็ตามอย่างที่คนอื่น ๆ สังเกตผมคิดว่าปัญหาพื้นฐานที่ทำให้เกิดปัญหานี้คือการใช้พารามิเตอร์มากเกินไป (IMHO, อะไรก็ได้> 3 นั้นมากเกินไป) และนั่นเป็นปัญหาจริงที่คุณควรจัดการกับ มีโพสต์ที่น่าสนใจเกี่ยวกับเรื่องนั้นในบล็อกของรีเบคก้าเมอร์ฟี่

ฉันคิดว่าเมื่อคุณมีข้อโต้แย้ง 1-3 ข้อการเรียงลำดับที่ถูกต้องค่อนข้างชัดเจนและคุณเพียงแค่ "รู้สึก" สิ่งที่ถูกต้อง

เช่นเดียวกับคำตอบของ @Wyatt Barnetts มีอะไรมากกว่าสองสามพารามิเตอร์หรือพารามิเตอร์ที่ชัดเจนมากสำหรับวิธีนี้ฉันขอแนะนำให้ส่งวัตถุแทน นี้มักจะง่ายต่อการปรับปรุง / การบำรุงรักษาที่ชัดเจนในการอ่านและขจัดความจำเป็นสำหรับการกังวลเกี่ยวกับการสั่งซื้อ นอกจากนี้พารามิเตอร์มากเกินไปสำหรับวิธีหนึ่งคือกลิ่นรหัสและมีรูปแบบการปรับโครงสร้างทั่วไปที่คุณสามารถปฏิบัติตามเพื่อช่วยแก้ไขได้

ตัวอย่างที่ชัดเจน:

public int add(int left, int right)
{
  return left + right;
}

เนื่องจากนี่เป็นตัวอย่างที่ชัดเจนและมีการสลับสับเปลี่ยน (ลำดับไม่สำคัญ) จากนั้นไปกับมัน

อย่างไรก็ตามหากคุณเพิ่มสิ่งที่ซับซ้อนมากขึ้น:

public SomeComplexReturnValue Calculate(int i, float f, string s, object o)
{
  // do work here
}

จะกลายเป็น:

public class SomeComplexInputForCalculation
{
  public int i; 
  public float f;
  public string s; 
  public object o;
}

public SomeComplexReturnValue Calculate(SomeComplexInputForCalculation input)
{
  // do work here
}

หวังว่านี่จะช่วย ...

สั่งมันในวิธีใดก็ตามที่คุณคิดว่าการแกงจะได้ประโยชน์มากที่สุด ตัวอย่างเช่นพารามิเตอร์ฟังก์ชันก่อน

"สำคัญก่อน" ไม่ได้มีความหมายมากนัก มีการประชุมบางอย่าง

หากคุณส่งผ่านออบเจกต์การโทร

ควรมีความคล่องแคล่วในรายการซึ่งหมายความว่าคุณควรรู้ว่าการโต้แย้งเกี่ยวกับเวลาที่คุณอ่าน ตัวอย่าง:

CopyFolder (เส้นทางสตริงบูลซ้ำ);

หากคุณต้องเรียกซ้ำก่อนมันจะทำให้สับสนเพราะยังไม่มีบริบท หากคุณอยู่ในขณะนี้มันเป็นเรื่องเกี่ยวกับการคัดลอก (1), โฟลเดอร์ (2) จากนั้นอาร์กิวเมนต์ที่เกิดซ้ำจะเริ่มต้นที่เหมาะสม

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

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

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