รหัสสะอาด: ฟังก์ชั่นที่มีพารามิเตอร์น้อย [ปิด]

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

ทั้งแนวปฏิบัติในการใช้ตัวแปรส่วนกลางและการส่งผ่านข้อโต้แย้งจำนวนมากในฟังก์ชั่นอาจเป็นวิธีปฏิบัติในการเขียนโปรแกรมที่ไม่ดี แต่การใช้ตัวแปรทั่วโลกสามารถลดจำนวนพารามิเตอร์ในฟังก์ชันได้อย่างมาก ...

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

สิ่งที่ฉันคิดคือมันขึ้นอยู่กับปัจจัยหลายประการ:

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

ในความคิดของฉันถ้าขนาดซอร์สโค้ดมีขนาดค่อนข้างเล็ก (เช่นน้อยกว่า 600 บรรทัดของโค้ด) มีฟังก์ชั่นมากมายตัวแปรเดียวกันถูกส่งผ่านเป็นพารามิเตอร์และฟังก์ชั่นมีพารามิเตอร์มากมายจากนั้นใช้ตัวแปรทั่วโลกจะคุ้มค่า แต่ฉัน อยากรู้ว่า ...

• คุณแบ่งปันความคิดเห็นของฉัน?
• คุณคิดอย่างไรกับกรณีอื่นที่ซอร์สโค้ดใหญ่กว่า ฯลฯ ?

ปล . ฉันเห็นโพสต์นี้ชื่อเรื่องนั้นคล้ายกันมาก แต่เขาไม่ถามสิ่งที่ฉันอยากรู้

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

... ตัวแปรเดียวกันถูกส่งผ่านเป็นพารามิเตอร์

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

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

คุณควรหลีกเลี่ยงตัวแปรทั่วโลกเช่นภัยพิบัติ

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

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

สำหรับดีกลิ่นสะอาดรหัส modular, พยายามที่จะติดกับหลักการรับผิดชอบเดียว ทำเช่นนั้นกับ structs ของคุณ (หรือวัตถุ), ฟังก์ชั่นและไฟล์ต้นฉบับ หากคุณทำเช่นนั้นจำนวนธรรมชาติของพารามิเตอร์ที่ส่งผ่านไปยังฟังก์ชั่นจะชัดเจน

เรากำลังพูดถึงภาระการรับรู้ไม่ใช่ไวยากรณ์ ดังนั้นคำถามคือ ... สิ่งที่เป็นพารามิเตอร์ในบริบทนี้?

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

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

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

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

ดังนั้นเมื่อคุณมีความคิดเห็นในบริบทที่น้อยกว่า 600 บรรทัด"การใช้ตัวแปรทั่วโลกจะคุ้มค่า"จากนั้นคุณจะแบ่งปันความคิดเห็นของลุงบ๊อบอย่างสมบูรณ์แบบ แน่นอนมันเป็นที่ถกเถียงกันว่า "3 พารามิเตอร์ที่มากที่สุด" เป็นตัวเลขในอุดมคติและหากกฎนี้บางครั้งนำไปสู่ตัวแปรสมาชิกมากเกินไปแม้ในชั้นเรียนขนาดเล็ก IMHO นี่เป็นการแลกเปลี่ยนที่ไม่มีกฎที่ยากและรวดเร็วในการลากเส้น

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

การมีพารามิเตอร์หลายตัวไม่ใช่ปัญหา แต่เป็นอาการที่คุณอาจมีปัญหา พิจารณาวิธีนี้:

Graphics.PaintRectangle(left, top, length, height, red, green, blue, transparency);

การมี 7 พารามิเตอร์เป็นสัญญาณเตือนที่ชัดเจน ปัญหาที่พบคือพารามิเตอร์เหล่านี้ไม่ได้เป็นอิสระ แต่อยู่ในกลุ่ม leftและtopอยู่ร่วมกันเป็นPosition-structure, lengthและheightเป็นSizeโครงสร้างและred, blueและgreenเป็นColorโครงสร้าง และบางทีColorและความโปร่งใสอยู่ในBrushโครงสร้างหรือไม่? บางทีPositionและSizeอยู่ด้วยกันในRectangleโครงสร้างซึ่งในกรณีนี้เราอาจพิจารณาเปลี่ยนเป็นPaintวิธีการในRectangleวัตถุแทน? ดังนั้นเราอาจจะจบลงด้วย:

Rectangle.Paint(brush);

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

Graphics.left = something;
Graphics.top = something;
Graphics.length = something;
...etc
Graphics.PaintRectangle();

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

บรรทัดล่าง: สำหรับคำแนะนำในการเขียนโปรแกรมและกฏเกณฑ์ต่าง ๆ มันสำคัญมากที่จะต้องเข้าใจเหตุผลที่สำคัญ

ควรใช้ตัวแปรทั่วโลกเพื่อลดจำนวนพารามิเตอร์ของฟังก์ชั่นหรือไม่?

ไม่

ฉันอ่านบทแรกของหนังสือเล่มนี้

คุณอ่านหนังสือที่เหลืออยู่เหรอ?

ทั่วโลกเป็นเพียงพารามิเตอร์ที่ซ่อนอยู่ พวกเขาทำให้เกิดอาการปวดที่แตกต่างกัน แต่มันก็ยังเจ็บปวดอยู่ หยุดคิดหาวิธีแก้ไขกฎนี้ คิดเกี่ยวกับวิธีการปฏิบัติตาม

พารามิเตอร์คืออะไร

มันคือสิ่งที่ ในกล่องที่มีป้ายกำกับอย่างดี ทำไมมันถึงมีความสำคัญว่าคุณมีกล่องกี่กล่องเมื่อคุณใส่อะไรลงไป

มันเป็นค่าใช้จ่ายในการขนส่งและการจัดการ

Move(1, 2, 3, 4)

บอกฉันหน่อยว่าคุณสามารถอ่านได้ ลองทำดู

Move(PointA, PointB)

นั่นเป็นเหตุผล

เคล็ดลับที่เรียกว่าแนะนำวัตถุพารามิเตอร์

และใช่มันเป็นเพียงกลลวงถ้าสิ่งที่คุณทำคือการนับพารามิเตอร์ สิ่งที่คุณควรนับคือความคิด! Abstractions! คุณทำให้ฉันคิดมากแค่ไหน? ง่าย ๆ เข้าไว้.

ตอนนี้เป็นจำนวนเดียวกัน:

Move(xyx, y)

โอ๊ย! มันช่างน่ากลัวจริงๆ! เกิดอะไรขึ้นที่นี่?

ไม่เพียงพอที่จะ จำกัด จำนวนความคิด พวกเขาจะต้องมีความคิดที่ชัดเจน ห่าคืออะไร xyx

ตอนนี้ยังคงอ่อนแอ วิธีที่มีประสิทธิภาพมากขึ้นในการคิดเกี่ยวกับเรื่องนี้คืออะไร?

ฟังก์ชั่นควรมีขนาดเล็ก ไม่เล็กไปกว่านั้น

ลุงบ๊อบ

Move(PointB)

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

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

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

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

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

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

แค่สองเซ็นต์ของฉัน

ฉันกับลุงบ๊อบเกี่ยวกับเรื่องนี้และยอมรับว่ามากกว่า 3 params เป็นสิ่งที่ต้องหลีกเลี่ยง (ฉันไม่ค่อยใช้มากกว่า 3 params ในฟังก์ชั่น) การมี params จำนวนมากในฟังก์ชั่นเดียวสร้างปัญหาการบำรุงรักษาที่ใหญ่กว่าและอาจเป็นกลิ่นที่ฟังก์ชั่นของคุณทำมากเกินไป / มีความรับผิดชอบมากเกินไป

หากคุณใช้มากกว่า 3 วิธีในภาษา OO คุณควรพิจารณาว่า params ไม่เกี่ยวข้องกันในทางใดทางหนึ่งดังนั้นคุณควรผ่านวัตถุจริงๆหรือไม่

นอกจากนี้หากคุณสร้างฟังก์ชั่นมากขึ้น (เล็กลง) คุณจะสังเกตเห็นว่าฟังก์ชั่นมักจะมี 3 params หรือน้อยกว่า แยกฟังก์ชั่น / วิธีการเป็นเพื่อนของคุณ :-)

อย่าใช้ตัวแปรทั่วโลกเป็นวิธีในการปัดเศษให้มี params มากกว่า! นั่นคือการแลกเปลี่ยนหนึ่งการปฏิบัติที่ไม่ดีสำหรับหนึ่งที่เลวร้ายยิ่ง!

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

ในกรณีง่าย ๆ นี่คือ DTO แบบง่าย ๆ ที่ไม่มีอะไรนอกจากพารามิเตอร์เก่าเป็นคุณสมบัติ

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

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

function <functionname>(var1,var2,var3,var4.....var(n)){}

ฟังก์ชั่นด้านบนจะได้รับการแก้ไขและเปลี่ยนเป็น [using array associative] -

data=array(var1->var1,
           var2->var2
           var3->var3..
           .....
           ); // data is an associative array

function <functionname>(data)

ฉันเห็นด้วยกับคำตอบของ robert bristow-johnson : คุณสามารถใช้ struct เพื่อผูกข้อมูลในเอนทิตีเดียวได้

ยกตัวอย่างจาก PHP 4 ดูที่ฟังก์ชันของลายเซ็นสำหรับmktime():

• int mktime ([ int $hour = date("H") [, int $minute = date("i") [, int $second = date("s") [, int $month = date("n") [, int $day = date("j") [, int $year = date("Y") [, int $is_dst = -1 ]]]]]]] )

คุณไม่พบว่าสับสนหรือไม่ ฟังก์ชั่นนี้เรียกว่า "make time" แต่ใช้พารามิเตอร์วันเดือนและปีรวมถึงพารามิเตอร์สามครั้ง มันง่ายแค่ไหนที่จะจำลำดับที่พวกเขาเข้าไป เกิดอะไรขึ้นถ้าคุณเห็นmktime(1, 2, 3, 4, 5, 2246);? คุณเข้าใจหรือไม่ว่าไม่ต้องพูดถึงเรื่องอื่น? จะถูก2246ตีความว่าเป็นเวลา 24 ชั่วโมง "22:46"? พารามิเตอร์อื่น ๆ หมายถึงอะไร มันจะดีกว่าเป็นวัตถุ

ย้ายไปที่ PHP 5 ตอนนี้มีวัตถุ DateTime ในบรรดาวิธีการที่เรียกว่าเป็นสองและsetDate() setTime()ลายเซ็นของพวกเขามีดังนี้:

• public DateTime setDate ( int $year , int $month , int $day )
• public DateTime setTime ( int $hour , int $minute [, int $second = 0 ] )

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

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

คุณอาจมีโครงสร้างต่อไปนี้:

<?php
$my_date = new Date;
$my_date->setDay(5);
$my_date->setMonth(4);
$my_date->setYear(2246);

$my_time = new Time;
$my_time->setHour(1);
$my_time->setMinute(2);
$my_time->setSecond(3);

$my_date_time = new DateTime;
$my_date_time->setTime($my_time);
$my_date_time->setDate($my_date);
?>

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

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

โอ้และอย่าใช้รูปกลม!

คำตอบที่ดีมากมายที่นี่ แต่ส่วนใหญ่ไม่ได้กล่าวถึงประเด็น ทำไมต้องเป็นกฎง่ายๆ มันเกี่ยวกับขอบเขตมันเป็นเรื่องของการพึ่งพาและมันเกี่ยวกับการสร้างแบบจำลองที่เหมาะสม

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

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

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

ยิ่งคุณใช้โซลูชันที่สองมากเท่าไหร่การบำรุงรักษาเพิ่มเติมที่มีค่าใช้จ่ายก็จะยิ่งสูงขึ้น

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

หลายครั้งที่ฉันได้พบว่าการจัดกลุ่มพารามิเตอร์จำนวนมากที่ถูกส่งไปปรับปรุงสิ่งต่างๆ

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

• ครั้งหนึ่งกับวัตถุฉันมักจะพบว่าบางสิ่งบางอย่างสามารถย้าย funtionality ที่วัตถุ stuypid นี้เห็นได้ชัด ปกติแล้วมันจะง่ายต่อการทดสอบและด้วยการรวมตัวที่ดีและการมีเพศสัมพันธ์ต่ำทำให้สิ่งต่าง ๆ ดีขึ้น

• ครั้งต่อไปที่ฉันต้องเพิ่มพารามิเตอร์ใหม่ฉันมีสถานที่ที่ดีที่จะรวมไว้โดยไม่ต้องเปลี่ยนลายเซ็นของวิธีการมากมาย

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

ด้วยความเคารพฉันมั่นใจว่าคุณพลาดจุดที่มีพารามิเตอร์จำนวนเล็กน้อยในฟังก์ชั่น

ความคิดคือว่าสมองสามารถถือมาก "ข้อมูลที่ใช้งาน" ที่ครั้งหนึ่งและถ้าคุณมีnพารามิเตอร์ในการทำงานของคุณมีnชิ้นส่วนต่าง ๆ ของ "ข้อมูลที่ใช้งาน" ที่จะต้องอยู่ในสมองของคุณได้อย่างง่ายดายและถูกต้อง เข้าใจในสิ่งที่โค้ดกำลังทำอยู่ (Steve McConnell ใน Code Complete (หนังสือดีกว่ามาก ๆ IMO) พูดอะไรบางอย่างที่คล้ายกันเกี่ยวกับตัวแปร 7 ตัวในร่างกายของวิธีการ: เราไม่ค่อยจะเข้าถึงมัน แต่อีกต่อไปและคุณกำลังสูญเสีย ความสามารถทำให้ทุกอย่างตรงไปในหัวของคุณ)

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

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

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

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

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

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

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

ฉันพบวิธีที่มีประสิทธิภาพสูง (ใน JavaScript) เพื่อลดแรงเสียดทานระหว่างอินเตอร์เฟส: ใช้ส่วนต่อประสานที่เหมือนกันสำหรับโมดูลทั้งหมดโดยเฉพาะ: ฟังก์ชั่นพารามิเตอร์เดียว

เมื่อคุณต้องการพารามิเตอร์หลายตัว: ใช้ Object / Hash หรือ Array เดียว

อดทนกับฉันฉันสัญญาว่าฉันไม่ได้หลอก ...

ก่อนที่คุณจะพูดว่า "param func เดียวคืออะไรดี?" หรือ "มีความแตกต่างระหว่าง 1 Array กับ funcs หลาย arg หรือไม่"

ก็ใช่ บางทีมันอาจจะบอบบาง แต่ก็มีความแตกต่างกันมากมาย - ฉันสำรวจถึงประโยชน์มากมายที่นี่

เห็นได้ชัดว่าบางคนคิดว่า ppl 3 เป็น # ข้อโต้แย้งที่ถูกต้อง บางคนคิดว่ามันเป็น 2 ดีที่ยังคงถามคำถาม "ซึ่งพารามิเตอร์ไปใน arg [0]?" แทนที่จะเลือกตัวเลือกที่ จำกัด การใช้งานอินเตอร์เฟซด้วยการประกาศที่เข้มงวดยิ่งขึ้น

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

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

function sendMessage({toUser, fromUser, subject, body}) { }

// And call the method like so:
sendMessage({toUser: this.parentUser, fromUser: this.currentUser, subject: ‘Example Alert’})